As the vowels of the English alphabet (A, E, I, O, U) are integral to the English language - both written and oral; so too are certain actions for addressing security in software - both web-based and traditional.
I’m often asked by companies to help document some of the essential actions they can take while attempting to build better, and therefore more secure, software. Let’s distill this down to five essential actions an organization can implement in order to build more secure software.
Artifact Collection
It is no mistake that artifact collection must be the first vowel in this list. As has been succinctly stated by others, metrics matter. You can’t be serious about improving something if you are unable to measure it. Measurement is required for establishing a baseline, for establishing goals, for calculating improvement and for determining success.
Many organizations are quick to establish artifact collection and measurement in one area of development such as requirements or bug tracking, but forget that this equally applies to more manual processes. This might include a process artifact such as an architectural risk analysis or a people artifact as to whether a certain developer has attended training. Regardless of the artifact type, a central repository for the collection, measurement and monitoring of artifacts is essential to building more secure software.
Enablement
The second action to consider is enablement. Enablement pertains to individuals and should include three core areas: education, resources and tools.
Education of development teams with respect to security has long been considered an essential element to designing, building and deploying secure software. This education can cover basic security principles, threat classifications, threat modeling, or perhaps cover even more fundamental topics such as essential practices for good software development. Education enablement should not be a one-time thing. Establishing a repeatable program that allows for refresher courses, growth and maturity is valuable to developing one of your most important assets in the software development process – the developer. Valuable progress has been made using bite-sized 15-minute web based training programs (which of course can be measured as an artifact) as an education enablement method.
Why have we entered such an era of unparalleled growth in recent years in the software industry? I believe it is because of access to resources. We have been enabled to grow and expand at a previously unparalleled rate due to access to online resources. Think Google. Why not enable the developers internally through a similar internal resource library? By establishing items in the library such as the previously mentioned web-based training, best practices guidelines or certified components, we enable the developer to focus on what they were meant to do – develop software. We don’t want our developers re-inventing the wheel. Why would we ask them to re-architect a method for validating an email address? We can enable them through access to a proven certified component which is stored in a resource library.
Enablement of people and process is also fundamentally addressed through tools. We all recognize that tools do not build secure software in themselves, nor do they fix the technical and logical issues which they are able to find. As an example however, they may enable the individual to understand these deficiencies and make intelligent recommendations. They enable the developer. By granting access to tools that are able to perform these assessments, we enable the developer to be self-sufficient, reducing time and costs in the software development process.
Incremental Security
I have seen countless security initiatives fail because the ocean simply would not boil. How many different security threats do you suppose there are? I don’t have a number for that. Any given security assessment tool may have hundreds to thousands to tens of thousands of different types of checks. It simply does not work to attempt to run tools and report on all findings. The ocean doesn’t boil and people are frustrated.
Incremental security testing is essential for a successful security initiative. Start with one or two high priority security issues that make sense for your organization. Secondly, I suggest you look for two commonalities between them: a common root cause and a binary pass/fail automated test that can not be contested. The benefit of focusing on a common root cause is that the developer does not focus on what happened, but why it happened. For example, Mitre reports that cross-site scripting (XSS) and SQL injection were the two most commonly reported vulnerabilities in 2006. Perhaps these are the two issues that you begin with.
Ongoing Security Testing
One of the core successes of the Agile development methodology is that it is both incremental and iterative. This means that the software is built early and often. This allows transparency early in the process to where the largest obstacles will occur. Should a problem arise, a decision can quickly be made as to whether the efforts should be redirected or canceled. Security testing is no different. It greatly benefits from ongoing, iterative analysis. While logical vulnerabilities should be architected out of the software during the inception and elaboration phases, technical vulnerabilities have the tendency to arise due to developer or implementation error. Remember, security is an emergent property of the software development process. That is, the vulnerabilities tend to emerge as the application is constructed and can continue to appear in the ongoing maintenance phase. By performing automated ongoing or iterative security testing, the software benefits from having the technical vulnerabilities discovered and corrected as early as possible. It is no secret that correcting issues early in the software development lifecycle represents significant savings for the organization.
Unify the Policy
I purposely want to stay away from the term “Unified Process” as I do not want to refer to a specific development framework. Instead, this last vowel is merely the recognition that a strong unified policy should exist – which may well include a core development framework. While every large (or small) organization practically has many methodologies or variations of a methodology for developing software, it has been recognized for some time that implementing a unified and consistent process and policy results in better quality software. While I do not want to go on about the merits of various frameworks such as Waterfall, RUP, XP, or Spiral, it is unquestionable that some level of discipline regarding the unification of the development process is valuable. A unified policy should include very fundamental concepts such as the defined code framework and certified components that will be used. Usage of proven, mature frameworks drastically improves the quality of software. This policy should also define the required feedback loops from internal, external and software sources. Going further, this policy would define the more manual techniques that are required outside of automation. Unification of these processes, tools and results are what establishes a more complete and unified policy.
--
Regardless of the actions taken in implementing a strategic software security strategy, or the discussion about what the priority should be, it remains infinitely clear that “something” has to be done. The statistics are against us. Perhaps these five action vowels don’t seem to map to your organization. I won’t argue. It is sufficient that we open the dialog about these actions. Me? The five vowels are easy to remember and I’ve seen these simple steps bring success: Artifact collection, Enablement, Incremental security, Ongoing security testing and a Unifying the policy.
Comments