The 7 Qualities of Highly Secure Software

Mano Paul

• Publisher: Auerbach Publications
• Year: 2012
• eBook ISBN: 9781466566545
• Topic: Computer Science
• Subtopic: Cyber Security
• Index: Computer Science

The 7 Qualities of Highly Secure Software provides a framework for designing, developing, and deploying hacker-resilient software. It uses engaging anecdotes and analogies-ranging from Aesop's fables, athletics, architecture, biology, nursery rhymes, and video games-to illustrate the qualities that are essential for the development of highly secure

Chapter 1

Quality #1: Security Is Built In, Not Bolted On

Go to the ant, thou sluggard; consider her ways, and be wise: which having no guide, overseer, or ruler, provideth her meat in the summer, and gathereth her food in the harvest.

—Proverbs 6:6

Prelude: The Ant and the Grasshopper

As a child, one of my favorite activities was to have my dad read and tell us the stories from Aesop’s fables. One story that left an indelible imprint in my mind is the story of the ant and the grasshopper. You may be familiar with this story, but for the benefit of those who are not, the story goes something like this.

In a field one summer’s day, a grasshopper was hopping about, chirping and singing to its heart’s content. An ant passed by, bearing along with great toil an ear of corn he was taking to the nest. “Why not come and chat with me,” said the grasshopper, “instead of toiling and moiling in that way?” “I am helping to lay up food for the winter,” said the ant, “and recommend you to do the same.” “Why bother about winter?” said the grasshopper; “we have got plenty of food at present.” But the ant went on its way and continued its toil. When winter came, the grasshopper had no food and found itself dying of hunger, while it saw the ants distributing every day corn and grain from the stores they had collected in the summer. Then the grasshopper knew: It is best to prepare for the days of necessity.

In a similar manner, when it comes to secure software, it is best to prepare for the days ahead. One must be proactive to infuse necessary security processes and controls throughout the software development life cycle and not just before software gets released or deployed, to make the likelihood of a successful hacker attack impossible or next to impossible.

Introduction

Quality #1 of highly secure software is that security is built into the software from the initial stages of its design, through development to deployment, versus being bolted on at a later stage in the software development life cycle (SDLC). However, because incorporation of security features can potentially take more time and cost the project more, arguments challenging the adoption of, or opposing the need for this quality can be raised by someone who is required to incorporate security from the get-go.

Challenges and opposition often take the form of questions or comments such as, “Why do I really need to take security into account when my organization is already hard-pressed for time to deliver the software to the customer?”; “Adding on nonfunctional features such as security controls hardly seems to add any business value to my project.”; “Incorporating security in the development life cycle is not only risky for my project, as it can result in the slipping of its deliverable date, but it is also going to be costly as I have to pay for the personnel resources needed.”; or “I don’t see the benefits of doing additional work at a cost when I don’t know for certain if the software we develop will even get hacked.” None of these questions or comments are invalid from a business perspective, and so they must not be ignored or viewed solely from a security vantage point.

Such opposition does not always come from the business users or project managers alone. Even from within the Information Technology (IT) organization, some have argued, “We already have a firewall, and we use Secure Sockets Layer (SSL) for secure transmission, so why do we need more security in our software?”; “Shouldn’t the networking and security team take care of protecting our company?”; or “Our Intrusion Detection Systems (IDSs) and Intrusion Prevention Systems (IPSs) should detect and prevent attacks against our company, correct?”

In essence, all these challenges to the adoption of secure software life-cycle processes and opposition to incorporate security controls from the start of a project are, in fact, attempting to answer this one question: What is the value-add for being proactive in building security into the software we develop?

Security Myths That Need Busting

Before we delve into answering the value proposition question, we must first recognize that some of these challenges are actually misconceptions that must be set correct. These are myths that need to be dispelled.

If we were to approach Jamie Hyneman and Adam Savage, the stars of the Discovery channel’s show called Mythbusters, and ask them about the most common software security-related myths that are common and prevalent today, it is highly likely that upon their research, they would compile a list similar to the one below.

1. We have a firewall.

2. We use SSL.

3. We have intrusion detection systems and intrusion prevent systems (IDSs/IPSs).

4. Our software will not be accessible from the Internet.

5. We have never been compromised.

6. Security is “Not my Job” but the responsibility of the service provider.

7 Security adds little to no value to the business.

Let’s take some time to dispel these myths.

Myth # 1: We Have a Firewall

Arguably, this is one of the most common arguments posed when it comes to incorporating security throughout the software development life cycle. Unfortunately, this is a remnant of an infrastructure security modus operandi and is extremely myopic. It often stems from the way companies have implemented security historically. In earlier days, there was clear demarcation between a company’s boundary and the outside world, and the role of a security professional was primarily network defense configuration and operations. For the most part, when people talked about a security professional, they were talking about a network security professional such as a firewall administrator.

I can still remember, in my early days of information security work, one of the clients I worked for was trying to build their application security program, but instead of finding the right talent to develop the program, they had chosen to move some of the network security professionals, who were familiar with firewall administration, into the application security group as consultants. The network architecture manager was also inappropriately appointed as the acting information security officer, and very soon it was noticeable that every solution that these network security professionals recommended for application security concerns was to implement a firewall. The repercussion this had was that the development team members not only had very little say in incorporating security into the software they designed, but they also started to become complacent about security, pushing it off as a network or infrastructure problem. These network security professionals had clearly not understood the application security domain and were providing incorrect guidance that created a placebo sense of security.

Another incident comes to mind: I was invited to be a panelist on application security at an information security conference and when asked about the trends in the arena of information security, I made the statement that the “Era of the network hacker is fading!” to express the fact that the types of attacks that are evident today are targeted at applications or software. I received an email from a person in the crowd telling me that I did not know what I was talking about. Upon further discussions with this individual, it was quickly apparent to me that he was, by profession, a network security firewall administrator. He and his manager had attended the talk and the issue that he was trying to address was not necessarily the veracity of my statement, but rather his personal job security. If his manager had taken my statement to be more than what was intended, it could potentially be misconstrued as a threat to this individual’s job. But the fact that can be substantiated from research findings is that more and more companies are falling prey to attacks that exploit weaknesses in software (applications). Gartner Group, in 2005, published that approximately 70 percent of attacks were targeted at the application layer.

The argument that we must be secure because we have a firewall in place is not only weak, but also misleading. In today’s computing environment, not only has the boundary that defined a company’s borders thinned out, but in certain situations this boundary is practically nonexistent. Take, for example, the trend that is evident in many organizations to leverage cloud computing. Here platforms, infrastructures, and software are consumed using an on-demand, pay-peruse subscription model. Companies purchase a subscription to the services provided by the software and not the software itself. Furthermore, depending on the type of cloud computing implementation, such as private/public or hybrid clouds, company data may not be housed within the boundaries of the company itself. In implementations where company data is housed externally in the cloud provider’s infrastructure, as in the case of a public cloud, your company’s firewall offers no protection at all.

Vanishing Boundaries

In today’s computing environment, not only has the boundary that defined a company’s borders thinned out, but in certain situations this boundary is practically nonexistent, thus requiring the need for secure software!

Additionally network firewalls provide no protection against attacks that originate from within the company. This group of attacks is perpetrated by individuals who are within the company or who have access to the internal systems of a company viz. the insiders. A disgruntled employee or someone who a competitor could have planted within your company are examples of threat agents who are insiders. Developers who defect and implant logic bombs in code, which is now part of the attack surface, also fit this profile. Sadly, the network firewall can do little to protect against the enemies inside the firewall.

The Enemy Inside the Firewall

Network firewalls provide no protection against attacks that originate from within the company.

Perimeter defense controls such as network firewalls have their place in software security as one of the first lines of defense. They are certainly necessary, but they cannot be the only control to protect internal applications. For example, firewalls are usually effective for ingress filtering of maliciously crafted packets, but when it co...

Table of contents

• Cover
• Title Page
• Copyright
• Contents
• Preface
• About the Author
• 1 Quality #1: Security Is Built In, Not Bolted On
• 2 Quality #2: Functionality Maps to a Security Plan
• 3 Quality #3: Includes Foundational Assurance Elements
• 4 Quality #4: Is Balanced
• 5 Quality #5: Incorporates Security Requirements
• 6 Quality #6: Is Developed Collaboratively
• 7 Quality #7: Is Adaptable
• 8 Epilogue
• Index