devopsy.kinsta.cloud

Category: DevSecOps

  • ZeroNorth Adds Analytics App to Advance DevSecOps

    ZeroNorth Adds Analytics App to Advance DevSecOps

    ZeroNorth today added an Advanced AppSec Risk Analytics module to its platform for orchestrating DevSecOps processes.

    John Worrall, ZeroNorth CEO, said the analytics tool pulls vulnerability data generated by a variety of security tools to provide both DevOps and cybersecurity professionals with a single source of truth for assessing security within an application environment.

    The ZeroNorth platform is designed to enable IT organizations to orchestrate multiple vulnerability scanning tools within the context of a larger DevSecOps workflow, and can apply analytics to a large pool of security data. That data can be viewed in the context of specific groups, such as a business unit or specific application development and deployment team, or within the context of whichever application generates the most revenue for the business, Worral said.

    Additionally, the Advanced AppSec Risk Analytics module will surface types of vulnerabilities detected and the vulnerabilities most encountered, ranked by criticality, along with other trends in types and number of vulnerabilities detected/remediated, such as the number and criticality of vulnerability findings per specific scanner. It also tracks the applications and entities scanned, number of vulnerabilities detected per application/entity and the applications/entities that have the highest risk.

    ZeroNorth

    Armed with that analytics data, Worral said it becomes easier for IT teams to prioritize and focus their efforts, in addition to identifying areas of the business that may need additional cybersecurity resources and training. IT leaders can also get a snapshot view of the top application security risks to better assess the organization’s overall security posture, Worral noted.

    The Advanced AppSec Risk Analytics module will also surface vulnerability remediation bottlenecks spanning multiple applications within the context of a software development life cycle (SDLC), Worral added. Longer term, Worral said the data collected by the ZeroNorth analytics application will also create an opportunity for the company to apply machine learning algorithms to DevSecOps.

    In general, Worral said the only viable path toward achieving DevSecOps is to foster more collaboration between developers and cybersecurity teams. Getting those teams on the same page in terms of the security data that needs to be analyzed is a crucial first step, Worral said.

    It’s still early on in the adoption of DevSecOps best practices within organizations, however, it’s apparent a lack of cohesion between software developers and cybersecurity teams about which vulnerabilities to prioritize is a major source of dysfunction. Cybersecurity teams tend to create long lists of vulnerabilities discovered within applications without providing much context. Developers are then left to weigh, on their own, when to address a vulnerability versus focusing on writing additional code needed to make an application delivery deadline. Developers take potential vulnerabilities seriously, but there are only so many hours in a day to write code.

    Unfairly or not, developers are being held more accountable for application security. The challenge – and the opportunity – is to find a way to make the entire DevSecOps workflow a whole lot less contentious by helping DevOps and DevSecOps teams more aware of which tasks should be prioritized when.

  • Rewind Acquires BackHub to Protect GitHub Repositories

    Rewind Acquires BackHub to Protect GitHub Repositories

    Rewind, a provider of a software-as-a-service (SaaS) platform for backing up cloud services, today announced it has acquired BackHub to gain control of a platform for backing up GitHub repositories.

    Based in Germany, BackHub adds a data protection platform to a Rewind portfolio that includes offerings for backing up everything from QuickBooks to Shopify. Fresh from raising an additional $15 million in funding, Rewind CEO Mike Potter said BackHub addresses a critical issue involving the protection of some of the most valuable intellectual property any organization has in a cloud service. GitHub, a subsidiary of Microsoft, is the largest host of source code in the world, with over 40 million users and 190 million repositories. BackHub claims it protects data in those repositories for more than 1,000 organizations.

    Rewind GitHub backup

    While GitHub itself is a reliable cloud service, the code residing in GitHub is subject to the same potential threats as it would be in any other cloud service. It’s not uncommon for a malicious actor to gain access to credentials that they exploit, for one reason or another, to delete or alter data – or, in the case of GitHub, code. BackHub makes it possible to back up code stored in GitHub to another cloud service where it can be easily recovered.

    Potter said the ultimate goal for Rewind is to make it possible to back up the entire cloud. Achieving that goal will require both additional acquisitions and internal product development, said Potter.

    In the meantime, the company is focused on providing data protection for specialized cloud services usually overlooked by other backup and recovery tool providers. For now, it leaves the backup and recovery of data stored on widely used cloud services, such as Microsoft 365, to other vendors. Rewind claims more than 80,000 organizations are using its platform to protect data, stored in a wide range of cloud services, that address a specific niche use case.

    Given the prominent role GitHub plays in software supply chains, it is not surprising that the code stored in Git repositories becomes a target for cybercriminals. Much of the intellectual property stored in those repositories is a high-value target for organizations looking to reduce the amount of time required to re-engineer a rival company’s functionality.

    Nation-states around the world have cyber-espionage programs aimed at gathering any type of digital asset that might benefit their military or economy. Naturally, copying code isn’t always enough when, in one fell swoop, add code that might derail that project long enough for them to catch up.

    Unfortunately, there have been some high-profile breaches involving software supply chains. The best way to determine if a project has been compromised is to compare code bases. Repositories, by definition, provide application development teams with version control capabilities. However, backing up a GitHub repository provides one extra layer of security that can make it easier to recover from a breach.

  • Survey Shows DevSecOps Progress in Larger Organizations

    Survey Shows DevSecOps Progress in Larger Organizations

    A survey of 250 U.S. and UK large enterprises with more $1 billion in revenue conducted by Security Compass, a provider of a platform for automating security tasks as application are developed, finds three-quarters (75%) have implemented DevSecOps processes on current application development projects.

    Rohit Sethi, CEO, Security Compass, said the State of DevSecOps Report published today makes it clear more organizations are starting to embrace security by design as they develop their applications. Nearly three-quarters of respondents (73%) said their organizations follow a “by design” approach that enables them to proactively address cybersecurity and regulatory compliance.

    The primary reasons respondents cited for embracing DevSecOps best practices were to improve security, quality and/or resilience (54%), followed by the ability to bring applications to market faster (30%). One of the misconceptions about DevSecOps is that it slows down application development and deployment. However, Sethi said, in practice, DevSecOps enables organizations to address security and compliance issues that would otherwise result in an application not being promoted into a production environment. Almost three-quarters of respondents (73%) noted that manual security and compliance processes slow down code releases. A full 96% said their organization would benefit from the automation of security and compliance processes.

    The biggest DevSecOps obstacles cited by survey respondents included technical challenges (60%), followed by cost (40%), insufficient time (39%), lack of education (38%), lack of skills (36%) and organizational inertia (35%).

    In terms of deploying applications, the biggest reasons cited by the 51 C-suite executives that participated in the survey were insufficient automation and lack of tooling, at 51% each. Organizational barriers came in a close third (50%).

    In the longer term, Sethi said it’s clear most organizations are shifting toward zero-trust architectures to make their application environments more secure. However, achieving that goal across a broad application portfolio will require more investment in both automation and, eventually, various forms of artificial intelligence (AI), said Sethi.

    It’s not clear to what degree smaller organizations will have the tools and resources required to fund adoption of the automation platforms needed to advance DevSecOps more broadly. There’s more awareness of DevSecOps than ever. The challenge is the tools and processes required to achieve it are not uniformly being pushed into the hands of the individual developer. In some cases, organizational leaders are encouraging developers to embrace DevSecOps without any practical guidance.

    Eventually, of course, every organization will embrace DevSecOps best practices, but the real question is, at what rate? The number of applications organizations are rolling out continues to accelerate, but reliance on DevSecOps best practices to ensure security and compliance remains uneven, at best. Larger organizations that have the resources required to fund these initiatives tend to be further along in their adoption journey. However, there is no correlation between organizational size and the ability to build and deploy secure applications. After all, a smaller organization may make up for what they lack in resources with a greater commitment to DevSecOps best practices.

  • BluBracket Community Edition of Secrets Discovery Tool now Available

    BluBracket Community Edition of Secrets Discovery Tool now Available

    BluBracket today announced general availability of a community edition of a tool that employs machine learning algorithms to discover passwords, tokens and other security vulnerabilities in code.

    Prakash Linga, BluBracket’s CEO, said application secrets stored in code enable cybercriminals to compromise applications in ways that can impact an entire software supply chain. The community edition of the company’s namesake tool scans commits to determine if any new risks were introduced, and will then block the staged files from being committed. It works with any continuous integration/continuous delivery (CI/CD) platform or integrated development environment (IDE) that supports pre-commit hooks, including VSCode, Jetbrains IntelliJ and PyCharm.

    Developers are then presented with a risk score based on the number of secrets discovered in their code. For example, an active token for Amazon Web Services (AWS) would receive a high score, while a a password in a test environment would be rated low.

    The Community Edition of BluBracket can be accessed via GitHub. The free version of BluBracket can be employed to scan up to 10 repositories and sharing reports in real-time, covering more than 50 types of secrets that might be employed using any programming language.

    Linga said BluBracket also cuts down on false positives by combining machine learning algorithms with a built-in rules engine. In contrast to open source tools, BlueBracket generates far fewer false positives, said Linga.

    Linga said the Community Edition is intended to help foster adoption of DevSecOps best practices among individual developers, in hopes that when those developers are hired, their organizations eventually license the full instance of BluBracket. The company views its tools as being complementary to both tools that surface vulnerabilities in code as well as secrets management platforms, which are often not employed as widely within an organization, Linga said.

    In the wake of recent high-profile breaches that embedded malware in widely-distributed applications, there’s increased focus on securing software supply chains. In some of those instances, Linga said, it’s probable cybercriminals discovered passwords and other secrets that were inadvertently exposed in code.

    However those breaches were enabled, it is apparent cybercriminals are becoming more adept at exploiting a weakness in one application to inflict maximum damage across an entire environment. It’s hard to say exactly what role secrets discovery is playing, but cybercriminals tend to prefer the path of least resistance when it comes to exploiting application vulnerabilities.

    Of course, the hope is that adoption of DevSecOps best processes will reduce the number of breaches by shifting responsibility for cybersecurity further left toward developers. However, that’s difficult to achieve without finding the simplest way possible of getting the security tools required into the hands of the developers that need them most.

  • CNCF Graduates Open Policy Agent Project to Manage Compliance as Code

    CNCF Graduates Open Policy Agent Project to Manage Compliance as Code

    The Cloud Native Computing Foundation (CNCF) announced this week that the Open Policy Agent (OPA) project, which many IT teams are employing to manage compliance as code, has officially graduated.

    Torin Sandall, co-founder of the OPA project and vice president of open source at Styra, whose compliance management platform is based on OPA, said formal recognition of OPA alongside other CNCF projects, such as Kubernetes, should help further adoption of the open source project that first took shape in 2016.

    Now being advanced under the auspices of the CNCF, the open source agent created by the OPA project is increasingly being incorporated into a wider range of compliance and security platforms. At the same time, more developers are starting to manage compliance as code across a wider range of applications. The ultimate goal is to make it easier to meet compliance requirements using a declarative framework so that responsibility for implementing compliance policies shifts further left toward developers.

    OPA uses a general purpose engine for enforcing policies that uses a set of rules that developers embed within applications using the Rego language. OPA has gained traction among cloud native application developers because it provides a means to enforce policies across a wide range of microservices.

    Sandall said going forward, the primary focus of the OPA project should be to develop and share as many integrations as possible. There are many instances where a use case for OPA has been created, but development teams simply don’t know that use case exists. As a result, many IT teams are attempting to employ compliance as code to address an issue that others have already solved, Sandall said.

    During its time as an incubation project managed by the CNCF, the security special interest group (SIG) within the CNCF conducted two external OPA security audits. The OPA project has also defined a security vulnerability disclosure process and a security response team.

    It’s not clear whether chief compliance officers within enterprise IT organizations have developed an appreciation for OPA. In theory, many compliance issues could be avoided if organizations mandated using OPA – or another approach to managing compliance as code – within their applications. Those compliance issues, of course, are multiplying as the number of compliance mandates expand globally. The challenge is that most compliance teams don’t have much visibility into the application development process.

    In the meantime, as DevSecOps processes continue to mature, it seems almost inevitable they would expand to include compliance mandates, most of which only exist to ensure some base level of security is present. Of course, developers may not want to be responsible for compliance mandates. However, the sooner compliance issues are addressed in the development process, the less likely they are to become DevOps’ problem when deployed in a production environment.

  • AppDynamics Partners With Cisco to Secure Application Runtimes

    AppDynamics Partners With Cisco to Secure Application Runtimes

    AppDynamics today announced its agent software, which it provides as part of its observability platform, now has the ability to enforce application security policies.

    Developed in collaboration with the security business unit of parent company Cisco, the Cisco Secure Application offering, available from AppDynamics, can detect attacks, identify deviations in application behavior and block attacks automatically.

    Gregg Ostrowski, a regional CTO for AppDynamics, said the goal is to make it simpler for IT teams that employ AppDynamics for monitoring and observing their IT environments to also embrace DevSecOps best practices. In effect, IT teams can now piggyback security for application runtimes on their existing investment in AppDynamics, Ostrowski said.

    The AppDynamics approach provides the added benefit of easy integration with the Cisco security tools to improve collaboration between DevOps and cybersecurity teams, Ostrowski said. Security details correlated with the application topology make it easier to share context in a way that identifies the actual business relevance of any security event, he added.

    As organizations accelerate digital business transformation initiatives, Ostrowski said the need to embrace DevSecOps best practices is becoming more urgent. The level of risk attached to these types of projects is significantly higher than with previous generations of applications, Ostrowski said.

    While most organizations appreciate the need for greater application security, there’s a debate about how best to achieve that goal. There’s general agreement that developers need to be more involved. However, shifting responsibility for application security to the proverbial left often comes at the expense of developer productivity. AppDynamics is making a case for enabling IT teams, that may already rely on its application performance management (APM) platform, to enforce policies defined by the cybersecurity team.

    Of course, there’s still a need to provide developers with the tools required to write more secure code in the first place. The debate is over how involved in the cybersecurity management process developers need to be after applications are deployed in a production environment.

    Arguably, the goal should be to enable both teams to accomplish their respective tasks in a way that doesn’t require a constant stream of meetings and updates. In the event a vulnerability is discovered, it’s critical for security teams to determine the threat level that vulnerability represents. Otherwise, remediation of that vulnerability will be just one more item in a long list of patches that developers are already working on.

    Regardless of approach, there are now myriad ways to improve overall application security. In effect, the same defense-in-depth approach that IT organizations have relied on to secure network perimeters can now be applied to application security as applications are both constructed and deployed. The most significant challenge is not so much finding the tools required to improve application security, as defining the processes through which best practices can be consistently applied.

  • OpenAPI Specification: Perception vs. Reality

    OpenAPI Specification: Perception vs. Reality

    The OpenAPI Specification (OAS) (formerly known as the Swagger specification) provides a way to describe and document REST APIs and their components. It includes details on endpoints, their operations, parameters needed for the operations, expected responses for every operation, authentication methods and even annotations. OAS is an easy format to learn and read, and can be understood by both humans and machines. As you might imagine, this kind of “accessible” documentation is useful and beneficial in a number of different use cases for both development and security teams.

    Developer Relationships With OAS

    For developers, OAS can be used to generate documentation for APIs. Proper documentation can help other developers figure out how best to integrate and use these APIs with their own application.

    Even so, many developers have a love/hate relationship with OAS. Let’s face it, documenting is a far cry from developing. Although it is easy to learn, the actual act of documenting is tedious, manual and time consuming. Frankly, it’s probably one of the least glamorous parts of a developer’s job, and, therefore, many developers only do the absolute minimum. As a result, OAS can be incomplete or, in some cases, missing entirely. Not to mention, when the API is updated, how often is the OAS updated, too?

    In the case of incomplete or nonexistent documentation, developers will muddle through with trial and error, even though this can slow down the development process.

    If out-of-date OAS proves an annoyance for dev teams, what’s the impact on security?

    Security’s Relationship With OAS

    OAS can be consumed by both humans and machines, and both are critical for security’s use of OAS.

    OAS helps security teams (humans) become aware that the API exists, since its documentation is often part of the CI/CD process.

    By examining an OAS file, a security team can understand what the API is supposed to do and, from that, determine if it conforms to or violates the organization’s security policy. As an example, security teams might use the OAS to make sure that authentication and authorization are being implemented correctly, and that sensitive data, like PII, is not being exposed.

    Security teams might also deploy tools (machines) that use the OAS to enforce policy based on what’s in the documentation. As an example, the OAS may specify that, for a particular parameter, a string should be expected; it should be no more than four characters and it should contain only letters and numbers with no special characters. By validating input based on what is defined in the OAS, security tools can check that the API does what developers intend it to do.

    This plan sounds great on paper, but …

    Perception versus Reality

    Imagine a perfect world, in which every API is well-documented as part of the development process. As that API makes its way through the development pipeline, it does so hand-in-hand with an associated OAS. At the appropriate time, before production, security is made aware of the API and the OAS, the team evaluates the details, validates that the API matches policy, gives the thumbs up and the API goes into production. Security and development teams live in harmony and everyone is happy.

    We don’t live in a perfect world. Instead, we must deal with questions such as:

    • Does the OAS exist? In the most extreme cases, the OAS doesn’t even exist. It was never created as part of the development process, so it can’t be used for any sort of awareness. These misses happen more often than you think, giving rise to the problem known as shadow APIs. These APIs slip through the cracks, and make it into production with no documentation at all. While you might be saying to yourself, “Our company would never let this happen!” you should also consider that numerous APIs are stood up by development teams as a test, as part of a beta or as a quick-and-dirty way to get something done. There are more of them than you think, and these shadow APIs create unrealized risk.
    • Is the OAS complete? In slightly less-scary territory, let’s consider an incomplete OAS. You might be saying to yourself, “We have a top-notch development team, well-defined development processes and strict policies around documentation. No API makes it into production without an OAS!” Perhaps, but the devil is in the details, and those details are often missed. I’ve worked with countless customers who have happily and confidently produced an OAS in which critical details don’t match the reality of the API. Sometimes they’re not complete. Sometimes they’re missing all together. The industry calls these missing details shadow endpoints. Yes, someone did produce an OAS, and security was aware of the API, but a lot of critical detail is missing.
    • Is it being kept up-to-date? Development cycles seem to be moving faster and faster, and as documentation is one of the least glamorous parts of a developer’s job, updates can be missed, dismissed or, at the very least, lag behind. We commonly see multiple versions of an API, and the OAS does not reflect the new capabilities of the latest version.

    While a non-existent or outdated OAS presents a modest concern for API visibility, it creates a substantial concern when trying to serve as the foundation for API security.

    You take a huge risk if you depend solely on OAS for security. More often than not, an OAS is not accurate, lacks critical details and is only as useful as the data you feed into it. Gaps, including shadow APIs, leave out critical details, making enforcement impractical.

    The inaccuracy of OAS leaves customers with two choices. You can either enforce security policies based on strict adherence, and risk blocking legitimate traffic, or you can enforce based on loose adherence and risk letting attacks through. In either scenario, your organization is unduly vulnerable, and significantly less secure than your dev teams intended or your security teams would like.

    OAS is Only a Starting Point

    OAS provides a great starting point for documenting your APIs. Don’t make the mistake, however, of basing your API security strategy on what’s in your OAS. It’s simply not accurate enough. Taking that approach will leave your company’s vital data and services at the mercy of API attackers who will quickly know more about your APIs and what they expose than your OAS does.

  • Tidelift Secures Open Source Software Supply Chains

    Tidelift Secures Open Source Software Supply Chains

    Tidelift today announced the general availability of a platform dubbed Tidelift catalogs, through which enterprise IT organizations can more effectively manage their open source supply chains.

    Donald Fischer, Tidelift’s CEO, says the Tidelift catalogs platform enables IT teams to curate, track and manage open source components that have been vetted and adhere to compliance requirements by Tidelift. The company is working directly with the maintainers of those open source projects to compensate them for making that additional effort, said Fischer.

    Developers can reliably pull components spanning common language frameworks like JavaScript, Python, Java, Ruby, PHP, .NET and Rust, with more programming environments to follow, added Fischer. Those components are made available via a Tidelift Subscription service.

    Fischer said Tidelift is going beyond merely scanning open source components for vulnerabilities. The company is ensuring that when developers access versions of open source components, those versions comply with specific sets of policies, said Fischer. As a part of that subscription service, Tidelift monitors components for vulnerabilities as they are discovered, and works with maintainers to implement updates as needed.

    While many organizations are starting to employ DevSecOps best processes, Fischer said the discovery of an issue involving open source components often comes far too late in the process. The Tidelift catalog approach ensures there are no last-minute surprise that are only discovered just before an application is about to be deployed in a production environment.

    Securing software supply chains has become a higher priority since it was revealed that cybercriminals successfully inserted malware into an application update made to network monitoring software provided by SolarWinds. That malware subsequently rippled across IT environments involving multiple corporate entities, as well as several Federal agencies.

    Of course, securing a software supply chain doesn’t happen overnight. Most IT organizations don’t have the processes and platforms required to vet open source components and frameworks. Tidelift is betting most of those organizations would prefer to subscribe to a service, rather than set up that infrastructure themselves. However, for organizations that require in-house monitoring of all the elements of their application development platform, Tidelift will make an on-premises edition of its platform available.

    As organizations become more dependent on software, the potential impact malware can have on their operations can be extensive. Organizations of all sizes should expect to be fielding inquiries from customers, suppliers and partners concerning the level of rigor being applied to their software development processes. In effect, they are going to demand to know the provenance of the software they are being asked to implicitly trust. In many cases, those inquiries will provide the incentive to accelerate adoption of DevScOps best practices.

    The days when organizations blindly used software with little regard to its origins are coming to a close. That doesn’t mean reliance on open source software is necessarily going to decline; however, it does mean application development teams will be held more accountable for the open source components they rely on.

  • DevSecOps Implementation: EDR/XDR

    DevSecOps Implementation: EDR/XDR

    We mentioned host intrusion detection and network intrusion detection in an earlier blog, and mentioned firewalls a couple of times in passing. Let’s delve a bit into the history to understand how these tools’ functionality has evolved over time.

    On the host side, we had virus detection, in one form or another, from early in the evolution of the Internet. The idea being that, if an antivirus program could scan your files, it could help protect you from malicious applications. Applied to an organization, if antivirus applications could scan all users’ desktops, it could help protect the organization. And it did kind of work. Most organizations were protected, at one point or another, by their antivirus software. Then, they realized the need to see more than what simply scanning files could show. A file that looked innocent on disk could assemble malicious code while executing, so runtime environments also needed to be watched. Generally speaking, the same antivirus companies led the charge into runtime protection. But there is more to protecting systems than simply looking at running applications. Scripts, even database entries, could be made malicious, and activity over time could indicate a bigger problem than a virus – an intrusion. This problem was the reason host intrusion detection was born. The idea that all of your system(s) needed protection all of the time created a mostly agent-based environment that monitored several aspects of the running system to watch for suspicious activity.

    On the network side, firewalls were implemented early in the growth of the Internet to allow limited access to corporate resources over the network. If no one ever needed to telnet to the machines on subnet X, the telnet port for subnet X could simply be blocked at the firewall, and no sleep need be lost over attempts to connect. Almost immediately after their inception, firewalls started logging attempts to access ports, and this information was made available to network administrators to review. This had an interesting impact on the management of hosts, because now, the firewall could inform network administrators if one of the internal hosts was constantly attempting to do something it shouldn’t be – possibly indicating an intrusion or a bad employee (more often than not, it turned out that undertrained, curious employees were just poking around). But firewalls – whether using whitelist or blacklist methodology – were fragile and/or interruptive. They also simply plugged holes in the perimeter without being proactive. That is when some bright people realized that, if you monitored streams running through the firewall, you could detect attacks and intrusions and offer admins proactive information about potential threats. That was the genesis of network intrusion detection (at least, as with all of these, as much of it as I can cram into a blog).

    But as time has moved on, there was a need for more. Network intrusion prevention was tried, but most organizations don’t want automated systems cutting off connections for fear of impacting real users. While it is still around, it hasn’t gained all that much traction. The next step was to “connect the dots,” so to speak. If the HIDS on host A was detecting a suspicious pattern of behavior, it only made sense to have the HIDS on the other hosts in the network take a look for similar behavior. Command and control of cross-HIDS installs is at the heart of endpoint detection and response (EDR), which gathers information from multiple HIDS agents and correlates it to get a more holistic view and alert on activity that a single host might not have noticed (a super simplified example: if the same user account tries to get super-user privileges with a single attempt on a dozen machines. HIDS might not raise a high-priority alert for a single attempt, but EDR sees twelve attempts on twelve different machines, not just the one on a given box, and can raise a high-priority alert).

    Extended detection and response (XDR) extends this information amalgamation and analysis to the network side, including attempts to gain access to the network (in our simple example above, imagine if the same user account tried to ssh into machines it doesn’t have network access to).

    As of this writing, EDR and XDR are using machine learning (ML) to perform faster processing of all the data they are seeing, and to limit false positives while raising critical alerts up to human operators. At this point in the ongoing feud between attackers and security personnel, I’ll go so far as to call it state-of-the-art. For now. Other attack vectors and XDR-defeating attacks will no doubt come along, and will have to be answered, but for now, if you have a publicly exposed network, it is the best you can get. Vendors have moved both EDR and XDR analysis to the cloud, ostensibly to improve analysis. It does reduce the amount of maintenance customers must perform, but cloud usage comes with an operational pricetag that prospects should understand before signing on the dotted line. Most mid-sized or larger organizations don’t have a storage or processing power shortage, so operational efficiency is what you are really paying for, in most cases. Make sure it’s worth the cost, and you have a plan if you lose access to that ML engine in the cloud.

    Meanwhile, keep kicking rear. Mark each day with, “At least we’re not SolarWinds,” and, remember: you’re doing your best to protect the org in a dynamic and hostile environment. Celebrate each day without a breach as a success – because someone did try.

  • A Pragmatic Approach to DevSecOps

    A Pragmatic Approach to DevSecOps

    In response to market and competitive forces, many companies are using DevSecOps to develop higher quality and more secure software. Whether that software is their own product or is a component of their product, quality – and especially security – have become required rather than optional. To accommodate the security requirements, some companies have adopted DecSecOps overlays to their software development process that can, and has, caused significant disruption.

    Barriers to DevSecOps Adoption

    The main barrier to the transition from DevOps to DevSecOps is organizational rather than technical. Many companies are already employing special security teams tasked with ensuring applications are secure and that policies are being followed. However, they tend to act as gatekeepers to the release process – nothing gets released without security testing. This approach is prone to be “too little, too late,” as the security team is usually involved near the end of the development life cycle. Attempts to “test in” security rarely succeeds. Security needs to be built in from the start; “shifted left” so that security is fully integrated into the process from the start. Let’s break down these barriers:

    • Lack of motivation and awareness:  There’s a lack of awareness about security issues, and about the risks and impacts security vulnerabilities pose to the organization in terms of liability and reputation. Vulnerability statistics make it clear that many companies are still not taking security seriously enough. This indifference remains, even when 63% of companies had, or nearly had, vital data breaches in 2019 and each breach cost an average of $3.9 million to deal with.
    • Distrust: Lack of trust between teams is expected in most organizations, but it’s particularly problematic between software developers and security teams. Developers view security as impeding their success, and security teams view developers as incapable of delivering secure software.
    • Poor Perception: The prevailing view of security is that it’s difficult to implement and somebody else’s problem. If security teams are solely responsible for security, then it’s easy for developers to delegate to them. Companies often think that security can be tested into the product at the end of development – with disastrous results. Vulnerabilities discovered at this late stage are more difficult to debug, with subsequent impacts on time-to-market, budgets, product quality and reputation.
    • Gatekeeping: The security team sometimes acts as gatekeepers of release candidates, which is a source of friction between developers, testers and security experts. Placing security as a last, QA-like step before delivering a release is too little, too late. Developers also don’t like other teams imposing restrictions on their work, which is an issue when trying to put security controls, like secure coding practices, in place.
    • Lack of integration: Without integrating security practices and tools through the entire development process, security improvement initiatives have trouble getting off the ground. In fact, the key tenet of DevSecOps is to integrate security practices into each phase of development.

    These barriers might seem daunting, but it’s not unlike other corporate cultural shifts. Security teams need to delegate aspects of security to development teams and integrate secure practices as early as they can in their work. Developers need training and understanding of how critical security is to their work. Developers already have an appreciation for safety and quality, but lack some of the basics of good security practices.

    It doesn’t need to be this way. However, removing these barriers won’t happen overnight, so a practical and gradual approach to improving security is needed.

    Easing Your Way into DevSecOps

    Transitioning to a more secure software development process across an organization rarely works when done with a “big bang” approach. There’s often lack of buy-in from the teams, and general resistance to change when new approaches haven’t proven themselves. The cultural barriers to adoption remain, and the initiative fails. As with any large task, it makes sense to start small; to learn and adapt before expanding to more teams. The move from DevOps to DevSecOps should be organic.

    Start Small

    The alternative to the doomed “big bang” approach is to start with a small, motivated team, where it’s possible to implement new practices from the very beginning of a project. By keeping the scope, and thus, the technical and business risk, of the project smaller, it is possible to allow time for learning and adjustments along the way. Think of this as an incubator project, where the results are analyzed and used to evaluate gains, losses, what went right and what went wrong. This team can learn, and then teach the larger organization what works and what doesn’t. Importantly, they set the standard for how to approach DevSecOps, and kick off the organic growth needed for a smoother transition.

    Starting small extends to the use of new tools, as well. It’s one thing for a small team to adopt new technologies, but they can be quickly overwhelmed. Static application security testing (SAST) tools can produce a lot of information. It’s important that initial projects concentrate on high impact, high probability vulnerabilities, first and foremost. It’s easy to get bogged down in the details, and discipline is needed to focus on the highest impact, and to get the most ROI out of new tools.

    Start at the Beginning (Or as Early as you Can)

    This is where “shift left” plays an important role in the transition to DevSecOps. A small team can introduce new techniques without a large initial impact on productivity. They can also start integrating security from the beginning, right at the concept phase of development. They can introduce new tools, and become proficient at using them. It’s at these early stages where the payoff is the greatest. Finding and fixing possible vulnerabilities, and adopting more secure design and coding practices, greatly reduces the downstream impact. It’s not hard to justify the effort, when security attacks and data breaches in production systems can cost millions in fixes, downtime and reputation.

    Measure Success

    The interesting thing about measuring DevSecOps success is looking at what isn’t there; security vulnerabilities and potential software weaknesses. To understand how well a new DevSecOps transition is working, it’s important to have a baseline of vulnerabilities that exist in your other applications. For example, how many vulnerabilities were discovered during security testing? How many vulnerabilities made it into shipping products? If these statistics are known, then it’s a case of measuring how well the new project does versus the baseline performance.

    Other metrics are important, too, such as measuring the number of vulnerabilities detected, identifying those that are true risks and those that were removed through corrective action. SAST tools provide information on a per-build basis, so it is possible to look at trends over time. You can evaluate the DevSecOps process in terms of vulnerability trends over time; are they converging to a goal? How quickly is the convergence?

    The ultimate measurement of success is a more secure product and, ideally, security testing at the later stages of development should find fewer vulnerabilities than in the past. After building in security and starting at the beginning with a shift-left approach, vulnerabilities are caught sooner and removed more quickly.

    Start your DevSecOps Transition

    The critical time to detect new security vulnerabilities is as soon as developers write new code (or test cases) before it’s submitted to a build or software control system. It’s also critical that tools work in your favorite development environment (be that VI, Emacs, Microsoft VS Code or Visual Studio, or any of a number of Eclipse-based environments). It’s at this point where SAST tools shift security improvement via automation to the earliest point in the development cycle. Finding and fixing vulnerabilities here is less risky, cheaper and easier.

    Equally critical is establishing an initial baseline inventory of your third-party software assets, whether that is open source, reused internal code from other projects and/or third-party commercial software. This is done at the very beginning of the project, about as shift left as it gets! Software composition analysis (SCA) is critical throughout the development process since the open source and third-party software that you depend on is likely to have updates and introduce new security threats over time (including after you release the product).

    Early adoption of SAST and SCA tools can have many benefits as part of your DevSecOps adoption. These tools used in conjunction with a security “built in” approach make this transition easier:

    • Improve security awareness by exposing vulnerabilities in existing code, third party software and newly developed code. SAST tools provide all the necessary information to fix potential vulnerabilities, but also provide an explanation of the severity and risk. Developers get more experience with the types of software weaknesses that lead to vulnerabilities, and learn to avoid them.
    • Illustrate ROI by measuring success, and have a goal in mind. Eliminating just one serious vulnerability justifies much of the investment. However, communicating this ROI is important, and needs to be put in the proper context of how costly and risky vulnerabilities are once a product is released.
    • Remove gatekeeping so that developers and the security team are working together. Security teams provide the security controls that developers need to follow with a “trust, then check” approach. Developers learn more about secure practices over time, and integrate that knowledge into their existing workflow. In the end, there is no security team gate at release, and all members of the team know and understand the state of the product.
    • Integrate security practices into software development gradually, starting with a small team and small project. As experience is gained, these teams train the rest of the organization on best practices.

    DevSecOps From the Ground Up

    DevSecOps is a way to build security into an application, and the transition from an existing CI/CD and DevOps process is made easier with the right approach. Successful transition depends on breaking down the resistance to security practices that exist in many organizations. A “start small and start early” approach is recommended where new techniques, processes and tools, such as SAST and SCA, can be integrated with less downtime and cost.

    Most importantly, you need to decide what the success factors are. Measuring success and the ROI of the effort is needed to grow DevSecOps organically within the organization. Tools and automation provide the data needed to show progress, but communicating the ROI needs to be done in business terms. In the end, success results in a more secure product, and reduces your company’s exposure to data breaches and cyberattacks.