College Degrees Now Available for Secure Software Development

Tracie Berardi, Program Manager, Consortium for IT Software Quality (CISQ)

 

Cybersecurity training and workforce development is a common theme and solution that’s proposed at conferences that discuss the challenges of cybersecurity and the future as we know it – developing, architecting and living within digital IT ecosystems. Who’s steering the ship? Do leaders understand the security threats and do their teams know how to develop secure, resilient and trustworthy systems for the future? For years, IT was siloed and focused predominantly on functionality. Web-based applications and services expanded the attack surface.

 

Amidst these fast-paced technological changes, there is good news for workforce development, because with a skills gap, comes opportunity.

 

The Software Engineering Institute (SEI) at Carnegie Mellon University is one of the premiere universities in the U.S. for software engineering.  The SEI has developed Software Assurance Curricula with support from the U.S. Department of Homeland Security.  The courses available include –

 

  • Master of Software Assurance Curriculum
  • Undergraduate Software Assurance Curriculum
  • Community College Software Assurance Curriculum
  • Software Assurance for Executives

https://www.sei.cmu.edu/education-outreach/curricula/software-assurance/index.cfm.

 

I spoke with Girish Seshagiri, EVP and CTO of ISHPI Information Technologies, who explained that in the United States we now have three community colleges that offer an Associate Degree in Secure Software Development based on the SEI curriculum and adoption guidelines.

 

Girish is passionate about this subject. He is on CISQ’s Board, co-chair of the National Initiative for Cybersecurity (NICE) apprenticeship sub-working group, and co-founder of the Community Initiative Center of Excellence for Secure Software (CICESS). CICESS promotes a dual model apprenticeship in partnership with community colleges. Girish’s employer, ISHPI, was an early adopter of the apprenticeship model at the ISHPI AIS Software Development Division in Peoria, IL. Students take college courses while participating in paid, on-the-job experience.

 

The CICESS GP project won the 2018 Innovations in Cybersecurity Education Award (curriculum category) by the National CyberWatch Center, a National Science Foundation-funded Advanced Technological Education Center at Prince George’s Community College in Largo, Maryland.

 

Here’s a recent article in Community College Daily: http://www.ccdaily.com/2018/08/ready-work-cyber-security-employees/

 

What Developers Should Expect from Operations in DevOps

Bill Dickenson, Independent Consultant, Strategy On The Web

 

Expectation Management

As DevOps becomes increasingly mainstream, it is essential that expectations are met for each group involved in the process. Part 1 of this blog focused on what operations should expect from the developers in DevOps  while this part (Part 2) will focus on what developers should expect from Operations. Managing both sides is essential to a successful flow.

 

To be successful, software must operate efficently on the target platform, handle exceptions without intervention, and be easily changed while remaining secure. It must deliver the functionality at the lowest cost possible. CISQ has evolved a set of quality characteristic measures that when combined with automated software tools, provide a way to make sure that the code delivered, delivers. To deliver on this, Operations must provide the right tools and the right processes to succeed.

 

Specifications for Continuous Release

 

DevOps dramatically increases the speed that application code is developed and moved into production and the first requirement is to design for speed. Specifications should be designed to be delivered in work “packets” that are smaller than typical waterfall design. CISQ research has shown that designing even long projects as a series of smaller fixed scope projects in the 1-3 month range dramatically improves stability and cost control. When staggered to allow continuous releases, the smaller packet design can make DevOps easier. As releases get “bigger” the corresponding risk management problems also get bigger. The success rate for the projects also increases with the reduced time frame.

 

Tools, Tools, Tools

 

As speed increases, there is no room for manual processes which are not only unpredictable but inefficient as well. One of the goals of streamlining the process is to deliver business value rapidly and that requires a better approach. The code delivery “pipeline” must be optimized to deliver an increasingly rapid flow.

  • Software Quality: In the previous blog we discussed CISQ recommendation for software quality. These should be part of the developer’s toolkit. Select a tool that can look at the whole portfolio as many security violations are in the spaces between programs. While there are some worthy open source analysis tools, this is an area where getting the best tool not only reduces the risk but also makes the process smoother. While the open source tools are evolving rapidly, the business case will more that support high quality tools. The entire pipeline should start with quality objectives.
  • Source Code Control/Packet Repository: One area where DevOps implementations report issues is in the software control process. Increasing the speed of development puts source code control at risk especially in legacy environments where the release cycle was measured in months. The faster “packet” design will stress the existing toolset. The Packet repository should hold the products of the entire process. Deployment tools become more important.
  • Codified and Comprehensive Risk Management: Many DevOps implementations fail when an unusually large amount of risk is introduced rapidly. Data center operations are not typically application risk aware and there is usually no codified process beyond the dangerous High-Medium-Low scale. In addition to investing in a better risk management process, the approach must contemplate both application and infrastructure.

 

Environments

 

As the pace quickens, environments need to be defined and available at a far more aggressive pace. Cloud-based services shine at this but hybrid environments work also.

 

  • Test environments: Testing will increase in volume as the more continuous flow drives repetitive testing. The process will drive considerably higher testing needs.
  • Test Data Management: Unlike quarterly and even longer cycles, it becomes almost
    impossible to manually manage test data. The “golden transaction” process where the data necessary to test is preloaded into the image, becomes increasingly critical. The test system images now need to include replicated environments that can be tested rapidly.

From Operations, Developers should expect specifications designed to be implemented more frequently, tools to support the process, and environments designed for application services. Both groups benefit from understanding each others’ needs.  

 

What Operations Should Expect from Developers in DevOps

Bill Dickenson, Independent Consultant, Strategy On The Web

 

Expectation Management

DevOps brings both the developers and operations processes into alignment. This blog focuses on what operations should expect from the developers while my next blog will focus on what developers should expect from Operations. Managing both sides is essential to a successful flow.

 

One of the major weaknesses in application development is that while software only delivers value when it is running, few universities or professional training organizations focus on how to make software operate smoothly. To be successful, software must operate efficently on the target platform, handle exceptions without intervention, and be easily changed while remaining secure. Security may sound like an odd addition here but studies continue to validate that many violations in security are at the application level. It must deliver the functionality at the lowest cost possible.  CISQ has evolved a set of quality characteristic measures that when combined with automated software tools, provide a way to make sure that the code delivered, delivers. Operations has every reason to expect that software will be delivered with these characteristics.

 

Setting SLA Measurements for Structural Quality Characteristics

CISQ recommends the following four OMG standard measures engineered into the DevOps process.   CISQ measures for Security, Reliability, Performance Efficiency, and Maintainability were developed by representatives from 24 CISQ member companies that included large IT organizations, software service providers, and software technology vendors.

 

1) Security Violations per Automated Function Point

 

The MITRE Common Weakness Enumeration (CWE) database contains very clear guidance on unacceptable coding practices. Delivered code should not violate any of these practices however the top 22 are considered the most egregious. They place an unreasonable burden on the infrastructure to protect.  Operations cannot plug the leaks between modules where the security issues occur.  The CISQ Security measure covers the Top 22 CWEs.

 

2) Reliability below 0.1 violations per Automated Function Point

 

In any code there are data conditions that could cause the code to break in a way that allows an antagonist to gain access to the system. These also cause delivery failures in the expected functionality of the code.  Reliability can be measured as weaknesses in the code that can cause outages, data corruption, or unexpected behaviors.  The CISQ Reliability measure is composed from 29 severe violations of good architectural and coding practice that can cause applications to behave unreliably.  

 

3) Performance Efficiency below 1.0 violations per Automated Function Point

 

Performance Efficiency measures how efficiently the application performs or uses resources such as processor or memory capacity.  Performance Efficiency is measured as weaknesses in the code base that cause performance degradation or excessive processor or memory use.  This has been operationalized in the CISQ Performance Efficiency measure.  In today’s relatively cheap hardware environment, violations of this have become common. Unfortunately, they also degrade the cloud readiness.

 

4) Maintainability violations below 3.0 per Automated Function Point

 

As code becomes more complex, the change effort to adapt to evolving requirements also increases. Organizations that focus on Maintainability have a lower cost to operate, faster response to change, and a higher return on investment for operating costs. Up to 50% of maintenance effort is spent understanding the code before modification. The CISQ Maintainability measure is composed from 20 severe violations of good architectural and coding practice that make code unnecessarily complex.

 

These 4 are the minimum requirements that operations should expect from developers. In the next blog we will discuss what developers should require from operations!

 

Tough Love for Software Security

Each day brings more reports of hacked systems.  The security breaches at Target, TJ Maxx, and Heartland Payment Systems are reported to have cost well beyond $140,000,000 each.  Are we near a tipping point where people stop trusting online and electronic systems and go back to buying over-the-counter with cash and personal checks?  When does the financial services industry reach the breaking point and start charging excessive fees to cover their losses?  Before we arrive there, IT needs to apply some tough love to software security.

 

Reports following the shutdown of a crime ring last summer that had stolen 130,000,000+ credit card numbers indicated that the weakness most frequently exploited to gain entry was SQL injection.  SQL injection???  Haven’t we known about that weakness for two decades?  How can we still be creating these types of vulnerabilities?  How can we not have detected them before putting the code into production?  Don’t you validate your input?  Don’t you wash your hands before eating?

 

What do we have to do to derail this hacking express?  What will it take to develop a global profession of software engineers who understand the structural elements of secure code?  We need some tough love for those who continue to leave glaring holes in critical applications.

 

Here is a tough love recommendation.  It is admittedly a bit whacky, but you’ll get the point.  First, we rate each of the code-based weaknesses in the Common Weakness Enumeration (cwe.mitre.org) on a severity scale from ‘1 – very minor and difficult to exploit’, to ‘9 – you just rolled out a red carpet to the confidential data’.  Next, we implement technology that continually scans code during development for security vulnerabilities.  Finally, we immediately enforce the following penalties when a security-related flaw is detected during a coding session.

 

  • Severity rating 1, 2 — “Come on dude, that’s dumb” flashes on the developer’s display
  • Severity rating 3, 4 — developer placed in ‘timeout’ for 2 hours by auto-locking IDE
  • Severity rating 5, 6 — developer’s name and defect published on daily bozo list
  • Severity rating 7, 8 — mild electric shock administered through the developer’s keyboard
  • Severity rating 9 — developer banished to database administration for 1 month

 

Okay, this is a bit much, but with the cost of security flaws to business running well into 9-digits, the status quo in development is no longer tolerable.  Here are some reasonable steps to take on the road to tough love.

 

  1. All applications touching confidential information should be automatically scanned for security weaknesses during development, and immediate feedback provided to developers.
  2. Before each release into production, all application code should be scanned at the system level for security weaknesses. 
  3. All high severity security weaknesses should be removed before the code enters production.
  4. All other security weaknesses should be prioritized on a maintenance or story backlog for future remediation.
  5. All developers should be trained in developing secure code for each of their languages and platforms.
  6. Developers who continue to submit components to builds that harbor security weaknesses should receive additional training and/or mentoring.
  7. Developers who are unable to produce secure code even after additional training and/or mentoring should be assigned to other work.

 

The latter recommendations may upset some developers.  However, as the financial damage of security breaches escalates, the industry must take steps necessary to ensure that those entrusted to develop secure systems have the knowledge, skill, and discipline necessary to the task.  Organizations must accept some responsibility for preparing developers and sustaining their skills.  Academic institutions need to incorporate cyber-security as a requirement into their computer science and software engineering curricula.

 

The cyber-security community is supporting many important initiatives, and IT needs to take advantage of them.  Good places to start include the CERT website (www.cert.org) supported by the Software Engineering Institute at Carnegie Mellon University, the SANS Institute (www.sans.org), and the Common Weakness Enumeration (cwe.mitre.org) repository supported by Mitre on behalf of the US Department of Homeland Security.  Ultimately, developers must be held accountable for their capability and work results, since the risk to which they expose a business has grown unacceptably large.  Tough love for tougher security.