Software Without Seat Belts

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

Imagine that when shopping for your dream car, you walk into the showroom and you are greeted by an immaculately dressed sales person, who after exchanging introductions and finding out your requirements, gives you a tour of all the cars and their features, goes over the pricing and then tells you the cars don't come with seat belts as a standard offering – but it can be included for an additional price.

In this day and age, in most developed countries and some emerging marketscapes, this would be unacceptable from the vantage point of safety. Why is it different then when it comes to software – developed in-house or purchased commercially off-the-shelf (COTS) – and security features that need to be built-in as a standard and not bolted on when needed?

We all have heard of vulnerabilities and exploits in software. Full-disclosure lists are rife with evidence of insecure COTS software. The chronology of data breaches maintained by Privacy Rights Clearinghouse substantiates that software developed internally is equally insecure.

Software insecurity could be attributed to various factors. The cost of incorporating security within resource and time constraints, increased project life cycles, delay in time to market, developer mindset and inadequate security training and education are some reasons why software is inherently insecure.

However, a rise in the incidence of software security issues, globalization and increased regulatory and compliance requirements mandate that software be secure. Requirement 6 of the Payment Card Data Security Standard (PCI DSS) that deals with developing and maintaining secure systems and applications is an example of compliance requirement requiring secure software.

Security in Software

So what is secure software? Secure software is designed, developed and deployed with security controls built in by default. Security controls should address, at the bare minimum, confidentiality, integrity, availability, authentication, authorization and auditing (CIA+AAA). While confidentiality deals with protection against disclosure, integrity deals with protection against unauthorized modification and availability deals with protection against denial of service. Authentication is about who is making the request for a resource, authorization is about the rights and privileges of the requestor and auditing is about recording critical events for historical evidence.

Security controls should be considered throughout the software development life cycle (SDLC). They need to be first designed and should factor in more than just functionality incorporating CIA+AAA controls. Security design also should consider internal policies and standards and external regulatory and compliance requirements. Attack surface scenarios should be considered and threat and risk should be modeled.

A secure design and architecture review milestone in your SDLC is a necessary checkpoint. Secure development should fit the design. Data that your software will handle should be validated for format, length and range. Access should be denied by default, and override settings should be monitored.

Secure code review, peer review and testing for security are important checkpoints in the development phase of your SDLC. In addition to designing and developing software securely, it is imperative that software be deployed securely. Software should never be run with elevated or administrative privileges in production environments.

A fundamental shift is necessary in terms of the mindset of developers – one that makes security second nature in software they develop. For this to happen, development teams need to be trained and educated in software security. Most developers write software without understanding the impact and repercussions of software insecurity. Effective training and education would target changing the behavior of the development teams to incorporate security in software.

It is akin to the driving class you took in a driving school, or from a relative, working at it until driving became second nature to you. Think about it: The next you get behind the wheel of your car, you won't step on the gas until are buckled up. Why then should you have to settle for software without seat belts?

Mano Paul, CISSP, MCAD, MCSD, Network+, ECSA (LPT) is a founder and president of Express Certifications, a professional training and certification, security consulting and product development company. He can be reached at editor (at) certmag (dot) com.

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone
Mano Paul


Posted in Archive|