So far throughout my blogs I have given; a basic introduction to both flowcharts and data flow diagrams, informed you all of the different types, the advantages, the construction of flowcharts and DFDs, the use of flowcharts in the healthcare system and for my final blog I’m going to concentrate on how DFDs can be used within web security requirements.
When identifying applications, process and data, a data flow diagram is a good place to start. As I said in a previous blog, a data flow diagram is to identify the process in a system and the data that flows in and out of the process. Data flow consists of four symbols; external entity, process, data flow and data store. Data flow documentation consists of the data elements contained in the flow as well as the entity associated with the data elements. An example of a data flow diagram with four symbols can be seen below:
Data flow diagrams can be useful in helping you specify your security requirements and to help when beginning a new web development project. Although there is a whole literature around the usage of DFDs, you don’t necessarily have to be fancy about it; you can just use simple boxes to illustrate where data will be stored and lines to indicate where data will be flowing.
This is a very simple example of a high-level DFD where the process and flow are easily understood.
A very important aspect is trust boundaries, where the data comes from or goes someplace where you don’t completely trust,for example the internet. When the diagram is drawn, they begin to look for security related issues. Threat Modelling is often used to pick out certain security related issues which may need to be addressed. Sometimes this can result in some complications and it is very easy to lose sight of where you are and what you are looking to achieve.
If you or your company have previous knowledge of Threat Modelling then you could use it.
Your data is stored in the data store. Ideally data should be stored in as little places as possible. In some cases you may be storing more data than what is necessary. If you are processing data which falls under Data Protection Legislation then you would need to encrypt any data which is stored on portable media, such as USB sticks or laptops. Devices which store sensitive or confidential information should be securely destroyed at the end of their life.
For data flows you should help you specify the security requirements that your application will need to meet. For example, now you should have a better idea of where you need to encrypt your data, perform validation, authenticate the user etc.
But,you need to be careful. There could be areas where there is data stored where you mightn’t have thought about. If it is stored externally, then you may need to think about mechanisms such as encryption.
Situations will arise sometimes, where you need to extract production data to assist in troubleshooting. This could mean enabling application logging, or copying files to other systems where it can be analysed. You should have procedures in place to make sure that this information is deleted when the troubleshooting has been completed. Also disable any logging which you may have turned on during the troubleshooting.
Data Flow Diagrams are a useful tool in helping you specify the security requirements that your application needs to meet. This is a is relatively simple and informal approach and is easy to understand. In particular, it does not use Threat Modelling techniques to analyse your risks.
This is my last blog so I hope you all enjoyed reading them and that they will be helpful to ye for revision 🙂 Best of luck to everyone in the exams 🙂