PM Articles > Alan S. Koch > Getting Started with Secure Software Development

Getting Started with Secure Software Development

by Alan S. Koch, PMP

Motherhood, apple pie, and security. Who could be against them? But developing secure software presents daunting challenges. Last time, in Secure Software -- Don't Be the Next Target!, we took a quick flyover of the 7 Touchpoints of Secure Software and concluded that our development teams probably lack the knowledge required to apply them.

Does this mean that our software will be full of holes until we have the time to hire security experts, train our people, and start building that capability? Not at all! Three of the 7 Touchpoints are things that we can get started on today: Code Review, Risk Analysis, and Security Requirements. Taking those first steps will give us the breathing room we need to build the capability to fully embrace all 7 Touchpoints!

Code Review

Reviewing code for known security bugs and risky programming practices is best done with static code analysis tools. (The word "static" indicates that these tools do not analyze the system as it is operating; they merely look at the source code.) There are many static analysis tools available that will flag potential security issues. So we start by searching the Internet for code analysis security.

From the many tools that are available, we pick out tools that fit our developers' needs:

  • Tools that analyze the languages they program in
  • Tools that integrate into the development environments they use

Then we check the reviews and pick out one that:

  • Is easy to use
  • Doesn't flag too many false positives (issues that aren't really issues)
  • Is kept up to date by the vendor as new exploits are discovered
  • Has rules that can be updated (so we can add our own criteria to the reviews)

After obtaining our chosen tool and learning how it works, we integrate it into our development process. This will include agreeing on questions like these:

  • When should code be analyzed? It is a good idea to use these tools after each code module is complete and compiles cleanly, but before any -- or very much -- testing or integration effort has been expended.
  • How will the tool output be used? Who will go through it and how will they decide what needs to be fixed?
  • How will these security fixes be prioritized in relation to other defects that may be found, e.g. in testing?

It is critically important that our developers are encouraged to use the static analysis tool and fix the issues it finds, and that they are rewarded for doing so. So we institute a policy that we will never, never, never penalize anyone because the tool found an issue in his or her code! That it was found and fixed early in the process is a very good thing!

Risk Analysis

We can begin using Risk Analysis to improve the security of our software even before we have anyone with any security training on our project. That is because the initial Risk Analysis is focused on business impacts that people in our organization understand well (as opposed to the threats, which require more specialized knowledge).

When analyzing risk, we identify the things that we need to protect and the bad things that could happen if those things are not protected. For this, we need to think about all three dimensions of Security: Confidentiality, Integrity, and Availability (CIA).

Confidentiality: What information needs to be kept from certain audiences? What functions should not be available to certain people?

For example: If we are a retail establishment, then our customers' credit card numbers must not be disclosed to anyone. If we are a medical service provider, then patients' medical information must be kept confidential. If we are a venture capital firm, then we must ensure that the Intellectual Property of the start-ups we are funding does not get out. If we are a bank, then tellers must not be able to approve payments.

These confidentiality needs are defined by regulations, business imperatives, and company policies. So they can easily be identified and documented by anyone in the company with the appropriate business knowledge.

Integrity: What information needs to be protected from corruption or loss, whether malicious or accidental? This is sometimes referred to as "non-repudiation" (that there is no need to question the integrity of the information).

For example: If we are a retail establishment, then the charges to our customers' credit cards must be accurate, and we must ensure they happen. If we are a medical service provider, then the accuracy of our patients' medical information is a matter of life and death. If we are a venture capital firm, then information about our financial stake in the start-ups we are funding is our life-blood. If we are a bank, then our customers' account balances must be accurate.

Sometimes Integrity needs are a matter of regulation, but more often they are a matter of staying in business and making money.

Availability: What information needs to be available to whom, and when? If information did not need to be available, then securing it would be easy -- we would just entomb it in a block of lead and send it to the bottom of the sea! But the information and the systems that process it must be available to the right people at the right times and in the right contexts.

For example: If we are a retail establishment, then the charges we have made to our customers' credit cards must be accessible to our customer support agents. If we are a medical service provider, then our patients' medical information must be readily available to the medical professionals who treat them. If we are a venture capital firm, then the information about the start-ups we are funding must be available to the analysts who are responsible for each. If we are a bank, then our customers' account balances must be available to the customers and to the bank personnel who serve them.

Again, these availability needs are driven by the nature of our business and the things that the stakeholders in the business processes need to do.

These types of risk analyses are accessible using internal company knowledge and resources -- unlike other kinds, which require specialized knowledge about current security threats -- and they provide a very important start. With this foundation, we can begin addressing Security Requirements while we build a more advanced security risk analysis capability in our project teams.

Security Requirements

We already have some security requirements on our projects: Users must login. Different users must have different permissions. Certain data must be encrypted. Our Security Requirements are the mitigations we design for the threats and security needs we know about.

The Risk Analysis described above will allow us to define a much more robust and complete set of security requirements. Each risk we identify is likely to require some sort of mitigation, and those mitigations will take the form of Security Requirements for our systems.

For example, if we are the retail establishment with the three risks (CIA) listed above, then we might add Security Requirements like these:

  • Ask if the customer wants us to save their credit card information and keep their answer in their profile.
  • If the customer does not want us to save their credit card information, then use our bank's payment processing app to finalize payment for orders so their credit card number is never in our system.
  • If the customer does want us to save their credit card information, then:
    • Store their credit card number on a back-end system that is not accessible from the web-based front end, and
    • Use the last 4 digits of the card number as a card identifier in the customer's web-accessible profile and to initiate purchase transactions

We Are Only Getting Started!

These three Touchpoints represent ways that we can start making progress toward building more secure software. But we cannot stop there, because while they provide us some protection, there are many more ways we are vulnerable.

Code Review: Coding issues account for nearly half of all vulnerabilities that can be exploited. Code analysis tools produce results that are best analyzed by knowledgeable people. Building up our team's security knowledge will allow them to make better judgments about the tool outputs, making the tools more valuable.

But that still leaves the more than half of all exploitable vulnerabilities that are caused by Design issues. No tools can help us there; only knowledgeable people can review Designs for security issues!

Risk Analysis: The business risks we discussed can be identified relatively easily. However, the more we know about the threats and exploits that are out there, the better job we will be able to do at identifying our business vulnerabilities.

On top of those are the risks that are due to the technology, system design, and programming choices we make. Those technical risks cannot be assessed or mitigated unless our people have specific security-related knowledge.

Security Requirements: As we mature our ability to do Risk Analysis, we will become more and more able to define requirements to mitigate those risks.

But on top of our own business environment and technical choices, there is a whole world full of people who are continually coming up with new ways to attack systems. The only way to address those external threats is to build up and maintain our knowledge of them so we can guard against them.

The Other 4 Touchpoints: Then there are the other 4 Touchpoints of Software Security: Abuse Cases, Risk-Based Security Tests, Penetration Testing, and Security Operations. To begin to address these Touchpoints, we need security-savvy people who have specific and up-to-date knowledge.

So in addition to the three Touchpoints we can make some immediate progress on, we also need to start immediately to upgrade our teams' security knowledge by training people, upgrading the depth and currency of their security expertise, and hiring a security expert if we don't already have one on staff.

That makes four things we can begin doing today:

  • Get a code review tool and start using it on each project,
  • Perform a business security risk analysis on each project,
  • Use that risk analysis to define better Security Requirements on each project, and
  • Start upgrading our software developers' security knowledge.

Let's get started!

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.