Early security engagement - critical or waste?

An axiom of information security is that early engagement in projects and the Software Development Lifecycle (SDL) will produce more secure systems. As I quite enjoy challenging axioms, here goes.

Early security engagement it is generally accepted as producing more secure systems because fixing defects earlier is cheaper than fixing them later:

Cost to fix a defectTime detected
RequirementsArchitectureConstructionSystem testPost-release
Time introducedRequirements5–10×10×10–100×

source: http://en.wikipedia.org/wiki/Software_testing

You can see this codified in industry accepted patterns and guidance such as the Microsoft Software Development Lifecycle and OWASP presentations. The Microsoft SDL has security involvement at all stages in the standard waterfall method including defining security requirements, establishing design requirements and threat modelling, performing security testing and developing security incident response plans and final checks prior to go-live. Interestingly they have also a model for Agile, although it seems like repeating the same steps for each release.

I have also been preaching this for many years but I have always had my doubts about the true difference that early involvement makes for the following reasons:

Show me the numbers
I have lamented before about lack of good data in our business, and the importance of everyone collecting good metrics to assist to remediate this in 20 or 30 years. This debate should be able to be tested by examining projects that have had security involvement (or lack of) at various project stages and the cost of fixing security defects and actual security incidents in each of these cases. Of course there are no such studies as no one collects this data. However if you do find one please send it to me because I would love to read it. Even the data showing that software defects costing a 100 times more post release compared to at requirements, is not specific to security defects, it is general to all software defects.

Security as enterprise processes and people
Another great axiom that security is not just a technology you implement but also processes and people. Being secure is not a binary state but a fluctuating landscape with the current level of risk changing as new threats and vulnerabilities emerge and new security controls are implemented. The effectiveness of controls also change with how well processes operate over time and are driven by the quality of people operating them.

When writing security requirements for a project some people look to our bible ISO27002 or all the companies policies and standards. However many of the ISO controls or requirements are implemented across the company rather than individual projects. Good examples are the existence of policies, standards and procedures, HR screening, contact with authorities and establishing security roles in the organization structure. Even requirements you could think are specific to a project are performed by enterprise processes and technologies for example: backup, BCP/DR testing, anti-virus, platform and database builds and network security (firewalls, IDS etc).

Major advancements in security only via security projects
Security requirements are no different to other requirements in that they are evaluated in terms of impact on project cost, time and quality / complexity. If you have a high risk project that will be processing credit card payments on internet facing systems but your company lacks some key security capabilities such as data loss prevention, removable media control and email encryption for exchanging sensitive data securely. Even if you specify these as project requirements it is highly unlikely that the project alone will be able implement these technologies, processes and people. These types of major advances in security capability require their own projects, with business cases and company wide deployment. Projects can contribute to the business case but my experience is that a project will not stand still waiting for these to be implemented and regulation or audit findings are more influential in gaining funding for these initiatives than projects.

On the other hand if these types of capabilities do exist, it goes back to my earlier argument - the project will benefit by implementing into this environment without needing any specific requirements in these areas early on.

Even on the very specific case of web application projects, specifying that input validation is required, ensuring this is in the design, performing testing to ensure cross site scripting and SQL injection vulnerabilites do not exist would seem very valuable. However this could be more effectively implemented via secure coding standards, developer training, having enterprise libraries for security functions so the developers do not have to write their own, integrating source code analysis and dynamic and static security analysis in the developer IDE on each build. These are all enterprise capabilities, beyond any single projects capability to implement.

Path of least resistance
When the initial wishlist of requirements is analysed via MoSCoW method it becomes difficult to justify optimal security requirements, especially design requirements. For example having all authentication and authorization controlled via a central identity and access management repository maybe ideal and provide the maximum risk reduction against excessive access. However each component having its own authentication and authorization database and a manual user access management process is probably the minimum requirement to mitigate the threat. Supporting federated authentication and single sign-on maybe the most convenient for users and partners and have the lowest long term cost of operation but having separate usernames and passwords certainly will be the cheapest, fastest and least complex to implement.

Therefore even early engagement in a project may not produce the best security outcomes unless of course these capabilities such as a central IDM, federated authentication, a central SIEM already exist and the patterns for integrating and using them are well understood.

Customizing cloud and shared services
Most IT projects these days would have some form of third party outsourcing often utilizing an existing cloud based or shared service. Here the opportunity and ability to make major security improvements even with early project involvement are severely limited. If you are client number 4,324,999 and your are requesting two factor authentication which the service provider is not offering currently even the chances of paying for it and implemented bespoke is very low as they want to keep a standard operating environment for scale and support. Controls against internal abuse and miss-use at vendors is dependant on whether they have it as an enterprise controls already than what a project can get implemented. E.g. Amazon is not going to suddenly implement a data loss prevention technology for all its staff with access just because you now want to use EC2.

My arguments are based primarily on a projects at end user companies rather than software development companies. I can see that when Microsoft was developing a new version of Windows, a detailed threat model that discovered untrusted access to a particular pipe and recommended that it be authenticated could cut off a vulnerability which on release would be a lot more expensive to discover and patch. However for companies that are using technology to enable and support the business, the axiom of early security engagement adding the best value for money may not be as applicable.

These companies could get a lot better return on investment by focusing security resources on building enterprise security capabilities rather than engaging early and fully during the lifecycle of projects - especially if they have a lot of projects. Consulting and engagement on projects could be limited and focus on aiding the project with integration with these enterprise capabilities, which can really add value to the project by cutting their security costs and time to market.

Photo credits: Flikr papalars

No comments:

Post a Comment


Written by