Home > Articles > Security > General Security and Privacy

Software [In]security: Software Security Training

  • Print
  • + Share This
Gary McGraw and Sammy Migues describe how training has changed, provide data showing it's importance, and explain why it's important to pick the right training for your organization's needs.
Like this article? We recommend

Training is an integral part of any enterprise software security initiative.  Not surprisingly, software security training has been around for a very long time.  I delivered my first "Introduction to Software Security" training course to a bunch of software architects ten years ago in 2001 just before John Viega and I published Building Secure Software.  The customer was a major bank, of course.  Since then, training has changed and tens of thousands of developers have experienced some kind of training.  These days we have Computer-Based Training (CBT) in addition to Instructor-Led Training (ILT), and there are boatloads of courses to choose between.

So why write about software security training?  Because many things have changed over the years when it comes to software security training, and we have more data than ever to draw from.

Old Lessons Still Apply

Back in February 2006 when the Software [In]security column was being published by IT Architect magazine, I wrote an article that posed the question "Is Application Security Training Worth the Money?".  The answer back then was:

    If the course you choose is 1) taught by software people, 2) focuses on design flaws as well as bugs, and 3) covers software security touchpoints, you'll find it worth the money. Otherwise you might as well spend it on beer.

Five years later, all of those early lessons still apply: 1) developers and other software professionals only pay attention to instructors with software chops, so make sure that your trainers are actually software people (and not just good network security people); 2) though security features such as cryptography and authentication systems are interesting fodder for courseware, make sure that you focus most of your training attention on uncovering and eradicating security defects in your entire software base; and 3) ensure that your training curriculum covers best practices from every phase in the Security Development Lifecycle (SDLC) from design through coding to testing to fielding.  Don't over focus on implementation level bugs like the OWASP top ten, and don't forget to include content for executives, product managers, and testing people in your curriculum.

What the BSIMM Data Have to Say About Training

Training plays a central role in the BSIMM.  It is one of the twleve key practices in the Software Security Framework and includes twelve particular activities divided into three levels.  Here's what the BSIMM document (now in its third major revision) has to say about training:

    The overall goals for the Training practice are the creation of a knowledgeable workforce and correcting errors in processes. The workforce must have role-based knowledge that specifically includes the skills required to adequately perform their SSDL activities. Training must include specific information on root causes of errors discovered in process activities and outputs.

Here are the activity data for the Training practice for all three versions of the BSIMM study.  For what it's worth, these data have a unique characteristic in the BSIMM since the levels of activities do not directly break into neat bands. Usually, level one activities (easy) are very commonly observed and the bands between levels are quite obvious.  That is, level two stuff (harder than level one) is less common than level one, but more common than level three (rocket science).  Only in the training practice are three of four level two activities more commonly observed than three of the four level one activities.  (There is enough discrepancy here that we may need to adjust the Training practice for BSIMM4.)

Here is one way to understand what is going on with these data. T1.1 Provide awareness training, T2.1 Offer role-specific advanced curriculum (tools, technology stacks, bug parade), and T2.4 Offer on-demand individual training all involve things you can buy and roll out.  We've seen great growth in all three of these easy-to-buy activities.  T2.2 Create/use material specific to company history is a more of a cultural thing, and we've seen the culture change toward this kind of openness in the Technology and Independent Software Vendor verticals, but not in the Financial Services vertical (where security issues are still in some sense "classified").  On the other side of the coin, T1.2 Include security resources in onboarding, T1.3 Establish SSG office hours, and T1.4 Identify satellite through training take real SSG person-hours and process inside of a given firm.  The implication here is that companies in the BSIMM study are adopting activities they can buy before adopting activities they have to create and staff.

This is an interesting enough trend that we plan to look into whether it applies to activities in the other eleven practices as well.

We have put off adjusting the Training practice in the model twice (between each major BSIMM release).  If the data trends continue into BSIMM4, we will likely need to demote three level 2 activities to level 1 activities and promote three level 1 activities into level 2 activities. That is a fair amount of change, but the data are beginning to demand it.

What We Have Learned Through Consulting

Cigital has been offering software security training since 2001.  We estimate that we have trained over 14,000 people since that time with ILT.  Around 2006, the market demanded (and continues to demand) standardized "Introduction to Software Security" training for all SDLC stakeholders and more advanced training for architects and developers (usually focused around technology stacks).

Cigital's CBT courses have been deployed to 105,000 or so students (developers, architects, testers, managers, business analysts, security operations folks, and others) since 2007.  A majority of clients are hosting our eLearning content in their own internal learning management systems for access by employees and contractors.  As you can see, the CBT headcount number outstrips the ILT number by a factor of 7.5.

We've seen some significant changes in the Training part of the software security market. First, most firms have come to realize they are not a special snowflake when it comes to writing secure code. For years, the vast majority of firms felt that software security training had to be an exact, customized match for their skill levels, their technology stacks, their SDLC, their coding standards, and even their IDEs. It took a while for many firms to understand that the origin of their XSS and CSRF bugs, for example, was probably not their choice of IDE or SDLC, it was rather tied up in how their code was being attacked based on its design and implementation.

Second, eLearning or CBT has become a necessity for large firms. There simply isn't enough time (nor are there enough dollars) to roll out classroom instruction for everyone. While eLearning should not be any firm's sole skill building endeavor, it is a valuable tool for aiming large groups in the same direction.

Third, there is a distinct trend towards shorter training modules that focus on specific problems and solutions. Even just a year or two ago, everyone wanted comprehensive modules that walked the student through a full story. Now that software security has seeped into the public consciousness, it appears that most students just want the answer, not the story of why it's the answer. (This is probably not a good thing, but it is a trend nonetheless.)

If You Build It, You Still Have to Make Them Come

Zooming further out from the data, one of the most common problems we are seeing in our own training delivery work is the problem of extremely busy developers not taking advantage of the training courses on offer.  This is especially true when it comes to CBT and eLearning.  The training is there, but nobody is taking it.

There are several techniques you can use to address this problem.  One tactic is to make training mandatory and tie successful completion to raises and promotions (draconian and effective, but not always appropriate in all company cultures).   A second tactic is to make sure that the training is directly relevant to the work a developer is being asked to do (right now).  This one is so important that we'll come back to it below under the guise of real-time training.  A third tactic is to provide incentives and rewards for completion of training.  Sometimes this can be in the form of career progression or other "gold stars."

In any case, all students must be given the time to take and absorb software security training. Trying to squeeze training into an already packed sprint isn't going to accomplish anything useful.

Real-Time Training

For all the analyst chatter about SAST versus DAST, hybrid analysis, and so on, software security does nobody any good unless the code gets fixed.  That's why training is so important.  We don't want to put all of our dollars into a "code as you see fit, we'll find the bugs later" hamster wheel of pain.  We want to avoid creating bugs in the first place!  (And in any case, we certainly want to fix those bugs that we do find.)

One idea is to squash newborn bugs before they are even commited to a code base.  This means getting between the keyboard and the code pile.  Real-time training can do this.  That's because training teaches a developer to prevent bugs from entering the code base rather than focusing on finding bugs using tools later in the process.

The simple idea is to integrate rudimentary scanning capability into the IDE itself so that as a developer is typing in a potential vulnerability, we immediately put a stop to it and show her a better way to proceed.  (Ironically, this is one of the ideas proposed way back in 2000 with the introduction of the world's first code scanner, ITS4: http://www.cigital.com/papers/download/its4.pdf.)  We have been experimenting with this approach at Cigital through a tool called SecureAssist and the results are very encouraging.  We are busy integrating the resulting toolset into our standard secure SDLC.

As a developer using SecureAssist works on code where risk could be introduced, guidance is automatically "pushed" to the developer, providing just-in-time information to reinforce training.  Just as a document spellchecker detects spelling and grammar issues, SecureAssist detects when risky code is created that could ultimately result in a security bug.

Software Security Training is Not Just for Us Geeks

Don't forget that software security training is not just for developers. Every stakeholder in your SDLC requires some software security training. This includes business analysts (who, with help, should consume threat models and misuse/abuse cases to make non-functional security requirements), architects, testers, development managers, software risk managers, and everyone who is tasked with either defining some part of a software security initiative or executing it.

In the most successful programs we've seen, training is an integral part of the software security initiative strategy. That is, it doesn't simply exist; it reinforces and promotes the local software security process while also imparting important skills. This requires a thoughtful, role-based approach that arms all secure SDLC stakeholders to get their job done.

  • + 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