Understand your system architecture
As early as possible, possibly as early as your solution definition phase, obtain and understand your system architecture.
- What are the applications and software components used in the system?
- How are the applications and components connected or integrated together?
- What are the types and the sensitivity of data stored in the system?
- Who are the end-users of the system and where are they located?
- What are the expected use case scenarios?
- What are the non-functional requirements (NFRs)?
Knowing all the software components and how they are integrated or connected is crucial when you plan out your network architecture (especially the firewall and network security zone) as well as in determining what security countermeasures are needed. Knowing the type of data and their sensitivity will tell you what you have to secure and how much effort it will take.
Developing the system architecture is beyond the scope of this document. We strongly urge you, as the security professional, to seek out the system architecture from your implementation team and understand it.
As part of defining the systems architecture, you need to identify your security requirements. This could range from identifying security regulations and standards your system has to comply with to developing your security threat model.
For example, applications in your system will have to comply with the Payment Card Industry (PCI) security standards if they capture, store, process or transmit credit card. If your system accepts credit cards, we strongly urge you to read the PCI DSS Strategy section of this document to understand the strategy around PCI DSS compliance.
Depending on the type of data you process or the environment in which you work, you may have to consider other regulatory requirements. For example, government projects may have to comply with Federal Information Security Management Act (FISMA). Systems that capture health information may have to comply with Health Insurance Portability and Accountability Act (HIPAA). Understanding and building your systems to be compliant will be significantly easier than trying to retrofit and address these security concerns close to your production “go live.”
In most cases, you should also plan time and resources in your project to include an audit of the system prior to production.
Also as part of your system definition, you should perform a security threat model for your system to understand, at a minimum, potential attackers and what assets they might be interested in; and as a result, the threats for which you need to build countermeasures. For example, knowing that remote attackers may want to anonymously browse your interoperability message queues should dictate specifying countermeasures such as message queue authentication. You should ensure all security requirements are factored into your system architecture early in your project lifecycle.