Any successful engineering endeavor requires a strong relationship between engineers and clients. Similarly, the success of a software security assurance program hinges on a key relationship: one between security and software engineering teams.
Software engineering teams are under a significant amount of stress. There are constant struggles for power, competing requirements to address, most lack standardization within their organizations — and they all have to meet time to market. Their focus is, and always will be, on meeting business needs. As a result, security will take a back seat, whether firms agree with it or not. Your software security assurance program must be focused on a strong relationship between security and software engineering, so you can make it easier for software engineers to deliver secure products. Here's what you need to know about this missing piece of the software security assurance puzzle.
Like any other relationship, the most important aspect of building a successful partnership with software engineers is speaking in a language they understand. Software security professionals sometimes use their own language to speak about various types of vulnerabilities, throwing out names such as "cross-site request forgery," "cross-site scripting," "SQL injection" and "clickjacking."
The language barrier becomes more evident when software security professionals talk about canonicalization or output encoding for recommendations. While these terms do describe the attack and remediation, they often leave the average software engineer confused and uncertain. The terms are simply not something the software engineers are used to hearing. Instead, software security professionals need to use terms software engineers understand.
Threat, risk and impact are important terms for managers, and sometimes even architects. When the conversation turns to these terms, most of the software engineers will usually wonder, "Who would ever do such a thing, and why?" While security professionals have either learned or always had the "How do I break it?" mind-set, most developers think more along the lines of, "How do I get the system running and functioning?" This is not something that is right or wrong — it's simply the nature of the priorities and goals of developers, who are in the business of getting a product completed. As software security professionals, it's important to be empathetic to this, and respect it.
How does a security professional communicate with respect? First and foremost, have the partnership attitude, and remember that software engineers always want to deliver quality products. Second, demonstrate the way in which security findings impact the quality of products in an educational way, being careful not to refer to the product as "your code" or "your application." Avoid negative phrases such as "poor" and "bad," and don't place blame. Lastly, demonstrate and provide pseudocode for fixes. Yes, there are a lot of examples of how to avoid SQL Injection — but how many examples out there show how to avoid administration privilege bypass?
The most important aspect of building a successful relationship with the software engineering team is this: The software assurance program must fit within the software development lifecycle. Any portion of the software assurance program that relies on software engineers, but requires them to do more work or wait longer, will simply not succeed. It will be viewed as an inconvenience. The most interesting aspect of fitting within the workflow is that the software assurance program can no longer state the content delivery mechanism is not important. It is very important. Any training or guidance material must be readily available where the software engineers can fit it in their regular workflows. Security testing tools must be deployed and executed in a manner that limits the impact to the developer. Developers have habits, and the tools must enable the developer to continue these habits and provide feedback quickly.
Are there times when management will ultimately have to make a call and dictate the direction? Absolutely. Will the above steps guarantee that the software engineering team will be on board? No. But these steps will go a long way to helping the security team gain a useful ally in ensuring a secure product is always deployed.
Photo Source: Morguefile