Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats //

Vulnerability Management

4/18/2019
02:30 PM
Sammy Migues
Sammy Migues
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

How to Raise the Level of AppSec Competency in Your Organization

Improving processes won't happen overnight, but it's not complicated either.

Every organization needs someone with the authority to set up governance over data and the software portfolio. That person would also have a defined seat at the executive table, contributing to the discussion around organizational risk.

It may be up to IT and software engineering teams to create infrastructure, set access controls, create custom applications, and configure environments to be resilient to attack and protect data, but it's problematic to have those groups decide what "security”"means, how to do it, and whether they're accomplishing it. The bar for "how secure" must come from someone who stands for the business—and the CISO is an excellent choice.

Getting the right person in place and equipping him or her to be successful is the first step in raising the level of software security competence.

Understanding all the components of production software, including components brought in at build time, also is a foundational part of software security competence. So is having:

  • A way to verify security adherence in the organizational software development life cycle (SDLC).
  • Policies and standards specific to software and data security.
  • A software risk-ranking method that shows where to focus your efforts when time, people, or money are short.
  • A method to rank software projects.
  • A defined point of contact for engineers to ask security questions and who keeps them apprised of their security responsibilities.

Hundreds of organizations now have formal software security initiatives (SSIs) that have taken them from a "penetrate and patch" mentality to a proactive approach. Raising the level of software security competency won't happen overnight, but it's not complicated, either.

Traditionally, software security teams implemented time-consuming testing, and engineering's waterfall and agile-fall processes mostly allowed time for it. The two teams usually coordinated well enough for each to do their job sufficiently, if not efficiently. Software security competency often focused on how many bugs the testing processes could find. That worked for those chartered with governance and risk reduction, but as software engineering began to rapidly evolve into agile processes, continuous integration/continuous delivery (CI/CD) toolchains, and a DevOps culture, that slow, bug-finding-at-the-end approach created unacceptable friction for the engineering group chartered with feature velocity.

In today's CI/CD and DevOps world, raising organizational software security competency doesn't mean using legacy security testing tools alongside engineering's new processes. It means integrating tightly with engineering to provide cadence-friendly CI/CD tooling and culture-friendly DevOps processes. It means taking all that "sec" the SSI learned over the years and making it fit in CI/CD and DevOps to create your organization's version of DevSecOps.

Of course, the SSI will still need solid fundamentals. Remember that software inventory? Does your inventory process still work when orchestration is bringing up and tearing down containers and virtual machines based with infrastructure-as-code automation? What about detecting in the SDLC whether required frameworks and APIs are being used correctly? There's no point in doing penetration testing on software we already know is broken because it was designed or built poorly; that can be detected and resolved very early in software development.

In a CI/CD and DevOps world, every organization must build good "observability," which is how well we can infer internal states of a system or process given its status or outputs. Good sensors tuned in accordance with nonfunctional security requirements and release acceptance criteria will tell everyone when the software is misbehaving, and the right people can immediately determine whether it's a defect, an attack, or something else.

If CISOs don't take the initiative now, their organizations will likely get into a variety of unproductive behaviors. Shadow IT groups will be doing cloud plumbing, shadow development groups will be creating glue code to make CI/CD tools talk to each other, shadow architecture groups will be making cloud blueprints that work but not securely, and so on. Once fielded, it may not be possible to unwind functioning, revenue-generating applications just because they didn't go through any security gates.

Every firm needs assurance that the CISO is enabling the rapid deployment of acceptably secure software, regardless of whether she can watch every part of every SDLC every minute of the day. "I need assurance that my software portfolio is appropriately secure at any given time" is a significantly more mature management proposition than "I must run this test on that software when it gets to the end of that process."

All stakeholders partnering so that everyone stays in cadence and improve together may be the greatest competency of all.

Related Content:

 

 

 Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.

Sammy Migues is a Principal Scientist at Synopsys. He is an information security visionary with a proven record of entrepreneurial innovation, intellectual capital development, practical business solutions, and performance optimization. Migues is the co-author of the Building ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19729
PUBLISHED: 2019-12-11
An issue was discovered in the BSON ObjectID (aka bson-objectid) package 1.3.0 for Node.js. ObjectID() allows an attacker to generate a malformed objectid by inserting an additional property to the user-input, because bson-objectid will return early if it detects _bsontype==ObjectID in the user-inpu...
CVE-2019-19373
PUBLISHED: 2019-12-11
An issue was discovered in Squiz Matrix CMS 5.5.0 prior to 5.5.0.3, 5.5.1 prior to 5.5.1.8, 5.5.2 prior to 5.5.2.4, and 5.5.3 prior to 5.5.3.3 where a user can trigger arbitrary unserialization of a PHP object from a packages/cms/page_templates/page_remote_content/page_remote_content.inc POST parame...
CVE-2019-19374
PUBLISHED: 2019-12-11
An issue was discovered in core/assets/form/form_question_types/form_question_type_file_upload/form_question_type_file_upload.inc in Squiz Matrix CMS 5.5.0 prior to 5.5.0.3, 5.5.1 prior to 5.5.1.8, 5.5.2 prior to 5.5.2.4, and 5.5.3 prior to 5.5.3.3 where a user can delete arbitrary files from the se...
CVE-2014-7257
PUBLISHED: 2019-12-11
SQL injection vulnerability in DBD::PgPP 0.05 and earlier
CVE-2013-4303
PUBLISHED: 2019-12-11
includes/libs/IEUrlExtension.php in the MediaWiki API in MediaWiki 1.19.x before 1.19.8, 1.20.x before 1.20.7, and 1.21.x before 1.21.2 does not properly detect extensions when there are an even number of "." (period) characters in a string, which allows remote attackers to conduct cross-s...