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
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
Unreasonable Security Best Practices vs. Good Risk Management
Jack Freund, Director, Risk Science at RiskLens,  11/13/2019
Breaches Are Inevitable, So Embrace the Chaos
Ariel Zeitlin, Chief Technology Officer & Co-Founder, Guardicore,  11/13/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-2916
PUBLISHED: 2019-11-15
qtnx 0.9 stores non-custom SSH keys in a world-readable configuration file. If a user has a world-readable or world-executable home directory, another local system user could obtain the private key used to connect to remote NX sessions.
CVE-2019-12757
PUBLISHED: 2019-11-15
Symantec Endpoint Protection (SEP), prior to 14.2 RU2 & 12.1 RU6 MP10 and Symantec Endpoint Protection Small Business Edition (SEP SBE) prior to 12.1 RU6 MP10d (12.1.7510.7002), may be susceptible to a privilege escalation vulnerability, which is a type of issue whereby an attacker may attempt t...
CVE-2019-12758
PUBLISHED: 2019-11-15
Symantec Endpoint Protection, prior to 14.2 RU2, may be susceptible to an unsigned code execution vulnerability, which may allow an individual to execute code without a resident proper digital signature.
CVE-2019-12759
PUBLISHED: 2019-11-15
Symantec Endpoint Protection Manager (SEPM) and Symantec Mail Security for MS Exchange (SMSMSE), prior to versions 14.2 RU2 and 7.5.x respectively, may be susceptible to a privilege escalation vulnerability, which is a type of issue whereby an attacker may attempt to compromise the software applicat...
CVE-2019-18372
PUBLISHED: 2019-11-15
Symantec Endpoint Protection, prior to 14.2 RU2, may be susceptible to a privilege escalation vulnerability, which is a type of issue whereby an attacker may attempt to compromise the software application to gain elevated access to resources that are normally protected from an application or user.