Home > Articles > Security > General Security and Privacy

Software [In]security: Software Security Top 10 Surprises

📄 Contents

  1. Software Security Top 10 Surprises
  2. Top Ten List
  • Print
  • + Share This
Gary McGraw, Brian Chess, and Sammy Migues interviewed nine executives running top software security programs in order to gather real data from real programs. In the course of analyzing the data to create a maturity model, they unearthed some surprises.
Like this article? We recommend

Using the software security framework introduced in October (A Software Security Framework: Working Towards a Realistic Maturity Model), we interviewed nine executives running top software security programs in order to gather real data from real programs. Our goal is to create a maturity model based on these data, and we're busy working on that (stay tuned here for more). However, in the course of analyzing the data we gathered, we unearthed some surprises that we share in this article.

Nine Top Software Security Programs

Of the twenty-three large-scale software security initiatives we are aware of, we chose nine that we considered the most advanced. Our nine organizations are drawn from three verticals: financial services, independent software vendors, and technology firms.

On average, the target organizations have practiced software security for five years and four months (with the newest initiative being two and a half years old and the oldest initiative being a decade old). All nine have an internal group devoted to software security that we choose to call the Software Security Group or SSG. SSG size on average is 41 people (smallest 12, largest 100, median 35) with a "satellite" of others (developers, architects and people in the organization directly engaged in and promoting software security) of 79 people (smallest 0, largest 300, median 20). The average number of developers among our targets was 7550 people (smallest 450, largest 30,000, median 5000), yielding an average percentage of SSG to development of just over 1%.

We conducted the nine interviews in person and spent two hours going over each software security initiative in a conversation guided by the software security framework.

We're currently in the midst of the next step of the process: analyzing the data and presenting preliminary results to the nine participants. We will develop and publish a maturity model based on the data we gathered. Our objective is to impose some science on the often messy and subjective field of software security. We figure we'll get about as close to science as Anthropology ever does.

Ten Surprising Things

During our analysis, some interesting patterns emerged from the soup. Without further ado, the top ten most surprising things we learned about real software security programs:

9. Not only are there are no magic software security metrics, bad metrics actually hurt.
Don't get us wrong — gathering metrics is important, especially when a large-scale initiative is involved. We noted a number of point metrics that multiple programs rely on, but even the most advanced programs don't use any sort of balanced scorecard approach. In several cases, we heard stories about metrics that were misused, abused, or ignored in such a way that they actually created a roadblock to progress. The best course is to build metrics that work for your organization, collect them continuously, and keep a weather eye out for feedback loops that point people in the wrong direction.

8. Secure-by-default frameworks can be very helpful, especially if they are presented as middleware classes (but watch out for an over focus on security "stuff").
Software security has always made much hue and cry about being proactive. Part of a proactive stance is creating things like software frameworks that everyone in development can use (and learn from). Modern software frameworks allow plenty of flexibility. By making sure that a framework is used in a secure manner (and providing real examples in code), an SSG can create something tangible that helps development get its job done. If you choose to do this, make sure you get beyond standard security features like crypto. For example a Struts framework can be set up to include input validation by default. If you define things properly, you can even enforce the use of secure-by-default frameworks with a static analysis tool.

7. Web application firewalls are not in wide use, especially not as Web application firewalls.
Web applications are a kind of software with major high-profile security concerns. Web application firewalls have been touted as a complete solution to Web application security problems by vendors while simultaneously being pilloried as utterly useless by the cognoscente. The truth must lie somewhere between these extremes. We were surprised to find that only two of the nine organizations we interviewed used Web application firewalls at all. But even these two didn't use them to block application attacks; they used them to monitor Web applications and gather data about attacks. In our view, the best use of Web application firewalls is to buy some time to fix your security problems properly in the software itself by thwarting an active attack that you are already experiencing. So go ahead and stop attacks at a network choke point, but don't forget to fix the root cause in the code.

6. Involving QA in software security is non-trivial... Even the "simple" black box Web testing tools are too hard to use.
In order to scale to address the sheer magnitude of the software security problem we've created for ourselves, the QA department has to be part of the solution. The challenge is to get QA to understand security and the all-important attackers' perspective. One sneaky trick to solving this problem is to encapsulate the attackers' perspective in automated tools that can be used by QA. What we learned is that even today's Web application testing tools (badness-ometers of the first order) remain too difficult to use for testers who spend most of their time verifying functional requirements. QA is involved in software security in many real software security programs, but in all successful cases, QA is staffed by software engineers.

5. Though software security often seems to fit an audit role rather naturally, many successful programs evangelize (and provide software security resources) rather than audit even in regulated industries.
A cursory glance at software security Touchpoints shows an emphasis on checking things once certain software artifacts exist (think code review, architectural risk analysis, and penetration testing). These kinds of activities can be imposed in two ways: as audit gates or as teaching opportunities. We were surprised to find a strong emphasis on setting up an SSG as a resource helping to evangelize software security and to teach people how to build better code rather than as an audit bureau. This pattern held even in many of the financial services firms we spoke with, where we expected a much stronger "we are the security overlords" approach. The old adage "you catch more flies with honey than with vinegar" apparently applies even to software security bugs.

4. Architecture analysis is just as hard as we thought, and maybe harder.
By now most everyone understands that software security problems come in two basic flavors: bugs at the implementation level (in code), and flaws at the design level. The organizations we talked to were almost all engaged in searching for both kinds of problems. If we're to have any hope of taming software security or even securing a particular system, it's critical that we pay just as much attention to design problems as we do to coding errors. Working on one without the other will simply "squeeze the balloon." In the last few years we've made great progress automating the discovery of software security bugs with static analysis tools and centralized code scanning, but we've made little progress at all on architectural risk analysis. Even well-known approaches to the architecture analysis problem, such as Microsoft's STRIDE model, turn out to be hard to turn into widespread practices that don't rely on specialists. The thing is, architectural risk analysis often uncovers staggeringly important problems. We discovered that even though important real problems were found using architectural analysis, software groups still found the process painful enough that it didn't become a regular part of their security efforts. Much work remains to be done on this important aspect of software security.

3. Security researchers, consultants and the press care way more about the who/what/how of attacks than practitioners do.
As Exploiting Software teaches, the attackers' perspective plays a central role in software security (hence the black hat in the yin/yang). Unless you understand how potential attacks really work and who really does them, it's impossible to build a secure system. However, though attack information is critical for SSG members, the notion of teaching work-a-day developers how to "think like a bad guy" is not widespread. The "bug parade" approach to software security gets some airtime, but it is not as important as the "learn how to build code properly" approach.

2. All nine programs we talked to have in-house training curricula, and training is considered the most important software security practice in the two most mature software security initiatives we interviewed.
Even though some of us have been agitating, evangelizing, and teaching about software security for over a decade, developers are still learning the basics of software security. Academia is making very slow progress on folding security into the basic Computer Science curriculum, so developers coming straight out of school know almost nothing about software security. In-house training is the answer for all of the large software organizations we studied. Among those initiatives that have been at it the longest, training is held up as the most important practice. Everyone involved with making software gets a dose of security training when they join the company, and everyone gets another dose as an annual refresher.

1. Though all of the organizations we talked to do some kind of penetration testing, the role of penetration testing in all nine practices is diminishing over time.
We were not surprised that every one of the programs we talked to practiced penetration testing (most using external firms) at one time or another. After all, there's nothing like smoking hot pen testing report to get an organization to admit it has a problem. However, as activities earlier in the SDLC are adopted, penetration testing begins to lose some of its luster. We found evidence that the role of penetration testing diminishes (but does not go to zero) as an organization gets a handle on the software security problem.

0. Fuzz testing is widespread.
What kind of "last bullet" is that on a top ten list?! Let us explain. Way back in 1997 in the book Software Fault Injection, Jeff Voas and McGraw wrote about many kinds of testing that can be imposed on software. We wondered whether security was a special case for software testing. One classic way to probe software "reliability" is to send noise to a program and see what happens, i.e., fuzzing. Somehow the security community has morphed this technique into a widely applied way to look for software security problems. Wow. Who would have guessed that reliability trumps security?

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020