There are only a few acknowledged industry security architectures. SABSA (best documented in Enterprise Security Architecture by Sherwood, Clark and Lynas) is probably the best known.
The various artifacts from this architecture include:
Each of these layers needs to be thought about in a considered way:
Why do you want X / How will it be used / Who will use it / Where should it be located / When will it be used?
Answering these questions will help understand if something already exists (with PHP most likely), and understand the communities we need to talk to to understand their needs and desires.
Then a risk assessment can be carried out to determine the relative risks of each area, and understand likely vulnerabilities based upon existing exploits.
Occasionally, this process will pick up areas where there are missing areas of functionality in PHP. This then ends up on the roadmap for later versions.
Training and awareness – DR / BCP – audit and review – authorization – administration – incidents – standards, etc
Often these areas are well covered. The trick is to bring them under the one roof and ensure we’re all driving in the same direction. Some of the issues in a standard security architecture simply don’t apply to a language, which is cool as it means less work.
Policy – classification – security services management – interop standards (WS Security et al) – audit trail, etc
This is usually left to the programs written in PHP, but PHP needs to provide these services. The OWASP Guide provides a great deal of best practices, so the main activity here is to determine if the standard PHP frameworks contain adequate API in each area. For example, PHP is sadly lacking a secure audit class.
For PHP, this is mostly about configuration, but also the rawest possible implementation of the security trumvirate: confidentiality, integrity, availability. Again, PHP may need to grow to allow all of the areas here:
A major win for security architectures in the last few years is the move away from crunchy on the outside, soft on the inside “edge” hardening towards trust boundaries. Identifying data flows from trusted components to other less trusted components is key to understanding the security risk.
Therefore, this can be used to identify those API which normally perform this transition on behalf of programs, such as echo/printf/ IO in general, and so on. Each of these major trust boundaries needs to be investigated to ensure that there is a safe way to make the transition, whilst a raw / unsafe way remains for those few programs that need the raw / unsafe way.
Conclusion for now…
Well, that about wraps up this explanation. In the next installment, I’ll start enumerating the current risks and identifying business drivers. This is an important first step to creating a security architecture which will be robust.