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

02:30 PM
Sammy Migues
Sammy Migues
Connect Directly
E-Mail vvv

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 a respected thought ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Data Privacy Protections for the Most Vulnerable -- Children
Dimitri Sirota, Founder & CEO of BigID,  10/17/2019
Sodinokibi Ransomware: Where Attackers' Money Goes
Kelly Sheridan, Staff Editor, Dark Reading,  10/15/2019
Tor Weaponized to Steal Bitcoin
Dark Reading Staff 10/18/2019
Register for Dark Reading Newsletters
White Papers
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-10-21
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Notes: none.
PUBLISHED: 2019-10-21
idn2_to_ascii_4i in lib/lookup.c in GNU libidn2 before 2.1.1 has a heap-based buffer overflow via a long domain string.
PUBLISHED: 2019-10-21
In FusionPBX up to v4.5.7, the file app\xml_cdr\xml_cdr_delete.php uses an unsanitized "rec" variable coming from the URL, which is base64 decoded and allows deletion of any file of the system.
PUBLISHED: 2019-10-21
In FusionPBX up to v4.5.7, the file resources\download.php uses an unsanitized "f" variable coming from the URL, which takes any pathname and allows a download of it. (resources\secure_download.php is also affected.)
PUBLISHED: 2019-10-21
In FusionPBX up to v4.5.7, the file app\contacts\contact_import.php uses an unsanitized "query_string" variable coming from the URL, which is reflected in HTML, leading to XSS.