staging-devopsy.kinsta.cloud

Tag: devsecops

  • The Secure Software Development Life Cycle: Syncing Development and Security

    The Secure Software Development Life Cycle: Syncing Development and Security

    Over the last five to 10 years, the nature of software development has shifted dramatically. Whereas large software releases occurred every six to 18 months in the past, current release schedules have become much more frequent. The waterfall model of software development has morphed into what we now know as the DevOps model.

    As a consequence, DevOps has instigated changes in the traditional waterfall security touchpoints. In essence, DevOps has changed the very nature of how application security needs to be implemented. To avoid friction in the development process, application security activities must be adapted to the new world of DevOps practices. It has to go beyond the basics of threat modeling, design review and two weeks of pen testing.

    Under DevOps, some development organizations now do software releases on a daily, weekly or bi-weekly cadence. But they’re still grappling with older application security models. As a result, development and security testing can be out of sync—you cannot conduct a two-week pen test on software that’s released weekly. These organizations need effective security assurance in their SDLC that’s good, quick, early and—above all else—automated.

    The Changing Nature of Software Development

    The way software is developed keeps changing. And it keeps accelerating. Application security needs to change to catch up. Automation will play a key role in enabling application security to maintain the pace of DevOps. DevOps needs automation to effectively deal with software release cadences that occur on a daily, weekly and bi-weekly basis as well as to increase agility generally within the SDLC.

    For example, DevOps accelerates when the automated pipeline embeds application security scanning into pre-commit checks. In this way, consistent levels of application security testing apply every time developers check in code, resulting in a fully automated check-in process. But automation doesn’t lock developers into the same level of security for every code change. For example, if the change only involves altering the color of a logo, heavy security scanning and manual won’t be necessary. At least not the way it would be if the application is accessing sensitive data.

    So, instead of giving developers quarterly SAST results, automation puts the code analysis right there in front of developers as they’re checking in code (via certain IDE plugins). Presenting the code analysis findings to developers, while they are still in the code, has several advantages:

    • The code is still fresh in the developers’ minds.
    • Coding problems can be caught earlier and more easily while developers are still thinking about the code.
    • It mitigates the risk of developers not remembering the code context at a later date.

    Overall, the more automation there is in application security the better it is for open source validation, container scanning containers, QA testing, API security and more.

    Automated Security Assurance and Out-of-Band Activities

    When it comes to implementing testing in DevOps, you must balance automated security assurance with out-of-band activities. That means it’s sometimes appropriate to slow down the automated security process. Even in a completely automated DevOps process you may need to slow down to make necessary changes. It’s true a code change, such as just changing the background color on a web app, may not be too risky. There’s no problem with automating that DevOps step and pushing out the change. But, if your web app interacts with customer data, you’d be prudent to slow down and take the next application security test out of band, and make sure you’ve got the procedure right because it’s much riskier.

    There are different levels of risk and severity within each release of an application. Development organizations need to accept this and adapt to each release’s potential risk and severity level. Then, they need to provide the appropriate level of security assurance and security coverage, whether that is automated within the DevOps workflow, performed out of band or some combination of the two.

    Life in the Fast Lane

    For DevOps organizations, one of two avenues beckons to them: the security express lane or the security slow lane. You could create an automated DevSecOps process across the development organization—the security fast lane. But, there’s no one-size-fits-all DevSecOps process for enterprises. That’s because there could be up to hundreds of development teams within an enterprise. And there’s not always a standardized process that all dev teams can follow. It’s a challenge to adapt automated security to each development team. Those in the security fast lane should use a security champion to work with the development team and be the point person to assist them with understanding application security needs and remediation guidance.

    In the security slow lane, individual development teams may still be enabled to go fast. The difference is that they will pick the SDLC tools that make the most sense for that team. Then, they should also pick the application security tools that make the most sense for them. The bottom line for organizations is that application security needs to involve an acceptable level of friction for developers to make DevSecOps work. If there is too much friction, developers will bypass application security in favor of expediting coding activities.

  • Survey Surfaces Root Causes of DevSecOps Tension

    Survey Surfaces Root Causes of DevSecOps Tension

    Results of a survey published by SaltStack, a provider of IT automation tools, suggests tensions between cybersecurity and IT professionals on the one side and DevOps teams on the other are running high. According to the survey of 130 cybersecurity and IT leaders, 70% of respondents said their organization is sacrificing data security for faster innovation, with most cybersecurity and IT managers making a case for prioritizing data protection over innovation, speed to market and cost.

    Alex Peay, senior vice president for product at SaltStack, said that while it’s unlikely cybersecurity and IT leaders will be able to slow down the pace of innovation within their organizations, the survey results make it clear IT organizations are struggling to keep pace.

    On the plus side, the results also show that cybersecurity and IT operations teams are working more closely together. More than half—54%—of cybersecurity leaders said they communicate effectively with IT professionals, while 45% of IT professionals concurred.

    Best DevSecOps processes are, of course, meant to bridge the divide between DevOps teams and the rest of the IT organization. The expectation is that by pushing more responsibility for cybersecurity to the left, the pressure on cybersecurity and IT teams would be reduced. However, DevSecOps adoption remains nascent at best—many DevOps teams still don’t have the tools required to implement security controls programmatically within their applications.

    Even when they do have the tools needed to add security controls, organizations need to set up workflows that will enable cybersecurity teams to verify that those controls have been properly implemented. Given the chronic shortage of cybersecurity expertise, the rate at which applications are being deployed and updated easily overwhelms the amount of time cybersecurity teams have available to analyze modules of code that are now often updated several times a week. Most cybersecurity teams are already struggling to keep pace with patches for existing applications, let alone any new application modules.

    Of course, there’s not a lot of love lost between developers and cybersecurity teams. DevOps teams generally blame cybersecurity teams for slowing down the rate at which applications are deployed. In fact, one of the primary reasons DevSecOps is gaining traction among developers is that it represents a way to remove cybersecurity professionals from the application development process.

    Cybersecurity professionals, conversely, often view application developers as the root cause of the cybersecurity problem. Too many developers are reusing modules of code without first making sure those modules have been updated to address a known vulnerability. To add insult to injury, whenever a new vulnerability is discovered days, weeks or even months may go by before developers address it. To be fair, however, cybersecurity professionals are not especially adept at prioritizing vulnerabilities; as far as developers are concerned, the list of vulnerabilities presented is just one in a series of bugs that need to be addressed. Unless otherwise directed, developers will focus on bugs that impact features and performance before a potential security issue that has yet to manifest itself as an issue impacting end users.

    In general, advances in DevSecOps are being made that should provide some much-needed relief to IT and cybersecurity professionals. It’s just slowing down the rate at which applications are deployed and updated might not be one of them.

  • GitHub Extends Scope and Reach of Repository

    GitHub Extends Scope and Reach of Repository

    GitHub today at its GitHub Satellite virtual conference announced it has made it easier for developers to either launch a project or join an existing project on its repository and has added collaboration tools directly within the platform.

    GitHub is also moving to advance DevSecOps by adding code scanning tools and making secret scanning tools available for private repositories, in addition to making available GitHub Private Instances to provide organizations in highly regulated industries access to a more secure managed implementation of the GitHub repository.

    Max Schoening, VP of Product Design, said GitHub Codespaces removes a lot of friction associated with starting or joining a project by enabling developers to spin up a project in seconds. In many cases, he said, developers never launch a project simply because the effort required was too great relative to the value of the effort.

    Available in limited public beta, GitHub Codespaces should not only improve developer productivity but also significantly increase the number of projects being hosted on GitHub, said Schoening.

    GitHub Discussions, meanwhile, will provide a threaded format to organize unstructured conversations without having to leave the GitHub repository. Scheduled to be available in beta shortly, GitHub Discussions should increase developer productivity in addition to providing a place for developers to maintain a frequently asked questions document. Over time, Schoening said GitHub expects millions of communities to be formed around GitHub Discussions.

    GitHub is also moving to make DevSecOps a natural extension of any application development project. GitHub Advanced Security Cloud provides access to native code scanning and secret scanning tools that can be embedded within the developer workflow. Currently in beta, GitHub Advanced Security Cloud is based on security tools it gained via its acquisition of Semmle last year. Every Git push can now be scanned using a CodeQL semantic analysis engine to discover vulnerabilities. GitHub Advanced Security Cloud is designed to be an extension of an existing GitHub Advanced Security service.

    Finally, GitHub Private Instances will provide a fully managed alternative that, among other things, allows for bring-your-own-key encryption, backup, archiving and compliance with various regional data sovereignty requirements. GitHub did not reveal, however, when GitHub Private Instances will be available.

    As GitHub continues to evolve as an arm of Microsoft, there is no doubt more IT teams will be embracing DevOps. The biggest challenge is often making it easy to get started. In fact, many developers may find themselves unconsciously embracing best DevOps and DevSecOps processes as they, for example, employ scanning tools baked into the GitHub repository.

    Of course, no one knows for sure whether organizations will continue the pace of application development projects in the wake of the economic downturn brought on by the COVID-19 pandemic. However, Schoening noted the amount of time between pull requests has declined on the GitHub repository, which he suggests is an indication of increased activity and productivity now that more developers are working away from the office.

  • Your Applications Are the Weakest Security Link

    Your Applications Are the Weakest Security Link

    Amazon, Microsoft and Google have much bigger security budgets than you do. They have hundreds of people all over the world ensuring that their infrastructure is secure. Their teams are constantly reviewing their code, looking for flaws, vulnerabilities and potential exploits. They monitor hacking forums and run attractive bug-bounty programs in order to remain proactive.

    Only a few years ago, kernel errors were prevalent. Now, Microsoft’s and Linux’ teams have nearly eliminated kernel vulnerabilities. For example, according to the CVE database, in 2017 Linux kernel had 169 code execution vulnerabilities, in 2018 only three and in 2019 just five.

    When it comes to the cloud platforms, the cloud providers indeed take responsibility for security of the cloud, while the customers remain responsible for security in the cloud–which is where the danger lasts.

    Solution architectures are distributed across public cloud and legacy on-prem environments. They contain the customer’s own software as well as open source and third-party products, over which the customer has no control. Proliferation of microservices significantly increases the amount of network interfaces. Growing release velocity leaves no time to identify and address potential security problems and configuration oversights.

    While the operating systems and critical infrastructure software are improving, the number of vulnerabilities in application software are growing quite significantly. The ability to alter existing applications or inject additional code allows attackers to turn legitimate software into malicious ones. This kind of vulnerabilities is listed in the “code execution” category, which happens to be the biggest group in the CVE database.

    Patching known vulnerabilities takes more than 50 days on average, while attackers need just a few minutes to utilize them. On top of this, there is a huge amount of unknown/unpublished zero-day vulnerabilities, frequently used by commercial attackers who pay for them and keep them to themselves.

    In the well-known Equifax data breach, malicious software infiltrated a legitimate web server using an Apache Struts vulnerability that allowed arbitrary code insertion. Since this attack occurred in 2017, the CVE database shows that Apache Struts has had at least five similar types of vulnerabilities.

    Basically, customer applications are and will always be the weakest and the most exploitable software. How do we protect them?

    Code execution vulnerabilities are exploited while the software is running. Some of the exploits do not leave any file system footprint at all—fileless malware. The exploit may happen days, or even months, into the execution session. The only reliable way to identify a break-in is to verify the software integrity in the same memory where the code is running throughout the entire execution session. Any change to the code or an addition of the unsigned code will compromise its integrity and therefore will be identified.

    Traditional, file-based, signature mechanisms will not help here, because the executable files are changed when they are loaded into the memory; therefore, it must be a special algorithm sufficiently robust to protect itself and the application software.

    Cryptographic signature uniquely identifies software just like human DNA identifies a person. This mechanism can be further used to provide applications with proper authorizations such as communication and information access. This will ensure that only applications with the right “DNA” can communicate with each other and access encrypted information, which is the ultimate Zero-Trust paradigm.

  • Securing Internet-Facing Portals

    Securing Internet-Facing Portals

    Against the backdrop of the current pandemic, barely a day goes by without another portal or web application being launched to help citizens and customers interact with governments and corporations. Bringing these applications to market quickly, and ensuring they can’t compromise the security of the organization, requires DevOps to embrace news techniques and technologies. So, how best can DevOps ensure these applications don’t become a backdoor for the bad guys?

    Additional Defensive Techniques

    In the OWASP Top Ten list of vulnerabilities in Web Applications, ensuring uploaded documents and images are threat-free doesn’t factor. Yet, these can be the Achilles Heel of any internet-facing portal or application. 

    The primary vehicle for smuggling malware into an organization is via documents and images. These are routinely embedded with malware, some basic, some extremely sophisticated, targeting the user or employee who eventually uploads the document. Alternatively, the concealed malware can attack the portal itself, for example, via a malformed document.

    This malware is sufficiently new and well-concealed that it repeatedly evades detection-based cyber defences and even modern AI technologies. Ensuring that what arrives via the portal is threat-free means finding additional defensive techniques that increase the security without slowing down the application. 

    Best Practice

    The UK’s NCSC has published a set of essential guidelines for anyone charged with the security of an application that must accept documents and images from the internet. In the NCSC “Pattern: For Safely Importing Data,” the organization describes a set of best practice guidelines for accepting documents from untrusted sources and recommends an approach called document transformation to ensure imported documents are threat-free. 

    Transformation is a mechanism whereby untrusted documents and images have the essential business information extracted from them. The originals are then discarded–along with any embedded threats. The business information is then verified and brand-new documents are then created and formatted to match the originals.

    Securing internet-facing portals - Figure 1_transformation engine
    Figure 1: Transformation engine.

    Once documents have been through the transformation engine they are completely safe and can be used without any further security measures.

    “Baked-in” Security Controls

    For the AppSec manager, transformation is a great approach to promote across DevOps teams. It can be accessed via cloud APIs and it adds an additional layer of security–conformant with security best practices–that helps ensure web applications and portals don’t become a backdoor for malware infiltration. 

    Securing internet-facing portals - Fig 2 python
    Figure 2: Uploading a Document via an API.

    Developers need a choice of transformation APIs, depending on the nature of the particular application. For example, some applications will require a simple upload/download API to transform a file, while other applications will need APIs capable of handling more complex tasks, such as event-driven workflows or moving files between different storage buckets.

    Securing internet-facing portals - Fig 3 AWS flow
    Figure 3: AWS Flow Using S3 API.

    Head Start

    The demand for web applications to accept uploaded documents into portals is only going to increase, and with it the risk of potential for compromise from concealed malware. The good news is that any DevSecOps professional building a web application or portal that must accept documents and images from the internet, already has a head start when it comes to building securely if they are using a serverless architecture.

    From a security perspective, the alternative to serverless architectures, machine images in the cloud, have the associated risk that if, for example, malware succeeds in compromising the machine, it remains compromised thereafter. With a serverless, cloud native architecture, there is no residual machine and, therefore, little residual risk.

    Another key point in favor of building on a serverless cloud-native computing model is that it devolves the responsibility of patching to the service provider. It is widely understood that unpatched systems are one of the main causes of cybersecurity breaches. Serverless architectures enable the developer to shift operational responsibilities and routine security tasks, such as patching, maintenance and upgrades, to their service provider. 

    The current pandemic has turbo-charged the demand for internet-facing portals and with it the risk of malware infiltration via uploaded documents and images. For developers, that means finding new defensive techniques like transformation that can be quickly and easily baked into the code to ensure uploads are threat-free.

  • One Identity Allies With HashiCorp to Advance DevSecOps

    One Identity Allies With HashiCorp to Advance DevSecOps

    One Identity, a provider of identity management software, has aligned with HashiCorp to make it easier for DevOps teams to implement best DevSecOps practices.

    Tyler Reese, a senior product manager for One Identity, said via a plugin for HashiCorp Vault developers can now securely manage, monitor, record and audit privileged and administrative access to their vaulted tokens, passwords, certificates, application programming interface (API) keys and other secrets residing in the Safeguard privileged access management (PAM) platform from One Identity.

    The goal is to make it easier for developers to securely access credentials stored within Safeguard without having to provide access to every credential used to access, for example, a packaged application that a developer is trying to provide access to via a custom application or vice versa, he said.

    The two companies are trying to bridge the divide between end user credentials managed by IT teams that have control over access to packaged applications and the way DevOps teams manage secrets within their custom applications, said Reese. DevOps teams increasingly need to integrate custom applications with packaged applications. The challenge organizations face is finding a way to securely provide that access in a way that doesn’t require internal IT teams to be overly involved in the application development process, he noted, adding by integrating with HashiCorp Vault, all the friction is taken out of the process.

    Based on a transparent protocol proxy software that inspects protocol traffic at the application level, Safeguard rejects traffic that violates policies defined by the internal IT team. That approach prevents unauthorized and unfettered access to data. IT teams can also monitor privileged sessions in real-time with the ability to execute various actions, such as terminating a session if unusual or unwanted behavior is detected. Safeguard also enables IT teams to rotate privileged access passwords to comply with a wide range of regulations, said Reese.

    As developers embrace DevSecOps they need to find a way to dovetail their efforts with existing password management processes. For the most part, DevSecOps remains aspirational within most organizations. There is general agreement that more responsibility for security should shift left toward developers. However, most organizations are still a long way from putting the tools in the hands of developers who need to extend existing DevOps workflows. In the absence of those processes and tools, DevSecOps often winds up being little more than a sermon that IT leaders give to development teams.

    On the plus side, the rate at which cybersecurity tools that are integrated with the continuous integration/continuous delivery (CI/CD) platforms on which DevOps processes depend is steadily increasing. As that trend continues to gain momentum, the relationship between developers and cybersecurity teams will evolve. Cybersecurity teams will continue to define controls and verify that they have been implemented. Developers will be held accountable for implementing those controls as part of the overall quality assurance process. The challenge now is getting everyone inside behind that cultural transition in advance of the tools that will be available soon.

  • Accurics Makes Infrastructure as Code More Secure

    Accurics Makes Infrastructure as Code More Secure

    Fresh off raising $5 million in funding, Accurics today launched a platform that analyzes the code employed to manage infrastructure as code for vulnerabilities as well as indicators of drift to create a threat model for cloud application workloads and then, if necessary, automatically roll back cloud settings to their last known approved state.

    Accurics CEO Sachin Aggarwal said rather than simply focusing on cloud infrastructure, the startup company’s platform analyzes vulnerability feeds, identity access management (IAM) privileges and other data to detect potential cloud security issues. That analysis can then be shared with third-party security tools to automate remediation, he said.

    Once the model is constructed, Accurics then monitors the application workload for changes that introduce risks and generates a topology for each workload in real-time to identify any potential indicators of drift away from the initial deployment settings. If the drift is due to a legitimate change, the code can be updated. If it introduces risks, IT teams can roll their code back to the last known secure posture using a “time machine” capability that Accurics has baked into its platform, he said.

    AccuricsThe Accurics platform takes a different approach to cybersecurity—rather than focusing solely on application programming interfaces (APIs) exposed by cloud infrastructure providers, it analyzes everything from the Terraform code used to programmatically install workloads to the container and serverless computing frameworks employed. In the future, Aggarwal said Accurics plans to add integrations with other infrastructure commonly employed in cloud environments, including Jenkins, Bitbucket and GitLab continuous integration/continuous delivery (CI/CD) platforms.

    That analysis surfaces violations of common compliance and cybersecurity practices based on Security Operation Center (SOC) 2, General Data Protection Rule (GDPR), Payment Card Industry (PCI), Healthcare Information Portability and Accountability (HIPAA), International Organization of Standardization (ISO), Center for Internet Security (CIS) Benchmark, Amazon Web Services (AWS) Best Practices and the AWS well-architected framework.

    Aggarwal said Accurics advances DevSecOps by making it possible for organizations to continuously assess changes within their cloud application environments. Most of the issues involving cloud security today can be traced back to errors made while using tools to programmatically provision cloud infrastructure. The Accurics platform helps developers and cybersecurity teams to collaboratively discover those issues, he noted, adding the overarching goal is to enable both teams to reduce risks by eliminating the most common mistakes that are made in cloud computing environments.

    As the relationship between DevOps and cybersecurity teams continues to evolve, it’s become apparent the first issue most organizations need to address when it comes to cloud security is visibility. Most IT teams are concerned about cloud security not because the platforms are less secure than on-premises infrastructure. In general, cloud infrastructure is more secure. However, because of a lack of visibility, it’s not as easy for cybersecurity teams to discover when misconfigurations create a known vulnerability. If that issue gets resolved, much of the resistance to cloud computing generated by security concerns will fade away.

  • Continuous Security Through Developer Empowerment

    Continuous Security Through Developer Empowerment

    Every organization is embracing DevOps to one degree or another. The business impact of shipping software quickly and adapting to market needs is so immense that it has become a requirement—you’re either heading toward DevOps or heading toward bankruptcy. Yet, while our need for speed has increased, so has our need for security—and combining both is far from an easy task.

    The key to achieve the DevOps velocity is developer autonomy. Developers and their surrounding application teams need to make daily decisions about what to build and how to build it, and they need to do them on their own. Bottlenecks appear when teams are required to get external approval, slowing down the process and eliminating the dev team’s sense of ownership. The resulting effects are subpar outcomes in applications and attrition of top performing developers. 

    Yet, security practices, unfortunately, often depend on such reviews. Security audits and reviews are the bread and butter of most security organizations, requiring experts to determine if a decision is secure or not. For security to work at the speed of development, this practice has to change and give developers the power to make security decisions. The only alternative is insecure software and deceleration of software version development.

    How can we achieve such developer empowerment for continuous secure software development? Let’s review some key practices, and look at ops practices for inspiration. 

    Mindset Shift: From Super-Hero Operators to Multiplier Engineers

    Site reliability engineering (SRE) teams hold the same responsibility for a service’s uptime as the sysadmins that preceded them. The change in the role came from how they achieved this resilience. SREs don’t handle most incidents, nor do they review all code that affects reliability. Instead, they engineer the tools to empower developers to handle oncall and build operable software the right way. An SRE should only be pulled in for the extreme cases, be it an incident or architecture review. 

    Security teams must operate in the same manner. Their job must be tactical, working to reduce their involvement in the process and giving more responsibility to the developers. Cases will arise where their expertise is needed, but general inquiries should be kept to a minimum. 

    Tooling Change: From Security Tools to Developer Tools

    Before DevOps kicked in, app performance monitoring (APM) was owned by IT, who used synthetic measurements from many points around the world to assess and monitor how performant an application was. These solutions were powerful, but their developer experience was horrible. They were expensive, which limited tests developers could run. They excelled in explaining the state through aggregating tests, but offered little value to a developer trying to troubleshoot a performance problem. As a result, developers rarely used them. 

    Then, New Relic came on the scene, introducing a different approach to APM. Their tools were free or cheap to start with, making it accessible to all dev teams. They used instrumentation to offer rich results in developer terms (call stacks, lines of code), making them better for fixing problems. This new approach revolutionized the APM industry, embedded performance monitoring into dev practices and made the web faster.

    The same needs to happen for application security. If developers are the ones making impactful security decisions, then the most important users of security tools are no longer security folks—but rather developers themselves. Security tools should therefore focus on achieving developer adoption first and foremost, even when it comes at the expense of more effort by the security person involved. 

    Governance Change: From Blocking to Monitoring

    One of my favourite DevOps adages is, “If it moves, measure it. If it doesn’t move, measure it in case it moves”. It embodies just how critical it is to successfully monitor your running application. While CI/CD pipelines help you get software to production, monitoring gives you the confidence to do it at speed. You don’t need to worry so much about shipping a bug when you’re confident you’ll find out about it quickly and revert or roll out a solution.

    Security needs to embrace this approach. Finding out a security vulnerability has just been deployed and acting on it is almost as good as blocking it just before it was deployed—and far less disruptive. But to embrace this, you’ll need to invest in monitoring. 

    Developers are the first step in the application process. It makes sense that they are also the engineers of security solutions. Empowering developers to make security-first decisions allows IT teams and security professionals to address different parts of the business, saves time in the development process and ultimately creates stronger applications and outcomes. 

  • Enterprise Inertia Slowing Down DevSecOps Integration

    Enterprise Inertia Slowing Down DevSecOps Integration

    DevSecOps has become an increasingly popular topic as enterprises grapple with the continuing challenge of improving their cybersecurity infrastructure. As the first quarter of 2020 has come to a close, are we making significant progress in fully integrating the development, operations and security functions in the enterprise?

    The term “DevOps” was first used in 2009 by an IT consultant, Patrick Debois. Little more than a decade later, the IT industry is evolving to DevSecOps in response to the global cybersecurity threat and the realization that a more concerted effort is needed to effectively mitigate risk.

    One of the challenges is that DevOps itself is still not fully utilized in many enterprises, making those organizations more reluctant to embrace the idea of adding tighter integration with security teams and frameworks. Anyone who has worked in an organization knows implementing a cultural shift is difficult at best and not an overnight success. Moving from DevOps to DevSecOps does require such a shift.

    From Inertia to Integration 

    The Oracle Java 8 end-of-life story is a great illustration of the need to better integrate security into development and operations. Java applications traditionally were developed and delivered, and the inevitable security updates became the responsibility of the operations team to update the Java Runtime Environment (JRE) on each system that would utilize the application. This inevitably became a struggle of compatibility issues that resulted in exceptions versus resolving the security issues by updating Java.

    Java 10 resolves this struggle by creating a more symbiotic experience where the runtime components are baked right into the Java application as it is built. With this change, the dev team needs to take ownership of regular updates to the application to resolve security vulnerabilities, but this shift is slow in coming. Java 8 applications are still a critical part of many operations, even after the end of life of version 8, and companies now turn to OpenJDK and Corretto Java to continue in the legacy model.

    This is where inertia comes in. Enterprises stick to legacy systems, such as the Java 8 applications, and continue the cycle of compatibility issues preventing updates required to resolve security vulnerabilities. They have little or no attention from busy security staff, which long ago moved on to critical projects like protecting against the next WannaCry.

    Better integration–putting the Sec in DevSecOps more front and center–can be done.

    Here are some considerations to move from inertia to integration.

    Take Charge

    The concepts of ownership and responsibility need to change. A development team that has created a specific product needs to be responsible for taking care of future application needs, such as patching updates. The old-fashioned “We developed it; now we throw it over the wall to operations” doesn’t work in an integrated environment. The team needs to continue responsibility into the operation phase. This ends the volleying back and forth on who “owns” updates, and makes bugs, fixes and patching the DevSecOps team’s responsibility. 

    Get Your Track Shoes on

    Thanks to the plentiful options technology offers, enterprises are using varied development tools, browsers and vulnerability scans. This adds up to challenges since traditional patching is no longer always possible. At the same time, failure to execute updates in real time leaves the enterprise vulnerable to threats. For example, Microsoft introduced the new Edge Chromium edition which utilizes Google’s Chromium open source framework. Google had three Chrome releases between this year’s regular January and February Patch Tuesday events. This meant Microsoft had to integrate Chromium updates in real time or delay resolution to critical vulnerabilities for its customers. As another example, if an enterprise has an internal browser that used Chromium, the same updates have to be pushed out to protect users from threats.

    Think Totality of a Fix

    The best way to achieve integration is to ensure security is baked in as part of the development and operations process from the beginning. Before a new product/application is launched, a united DevSecOps team will be aware of all the components in that product, all the vendors who will have updates related to those components and the expected cadence of these updates. For enterprises updating a web or SaaS-based application, updates should be doable fairly quickly.

    Make Security First

    Time-to-market pressures abound but the strategic DevSecOps professionals are placing risk mitigation before operational impact. They are doing this in a landscape in which cyber hygiene continues to be an issue. Legacy systems are not being patched correctly; updates are being done too late, or not at all. To counter this, enterprises need to adopt a security first principle and improve the timeliness and thoroughness of patching and updates.

    Know Your Vendors

    A must-do is for DevSecOps to fully investigate what patching/updates a particular third-party vendor provides, what their release cadence is and what risk exposure it may present by not covering certain releases/companies. As part of this scrutiny, discern which vendors are responsive to security risks and which are not. With so many companies–Microsoft, Oracle, et al.–executing varied release schedules, adding automation into DevSecOps can further ensure updates are done in real time and cyber hygiene can be improved.

    Fulfilling the DevSecOps Promise

    DevSecOps can begin to reach its potential by paying attention to the people factor and using technology as a support rather than another headache. Whether an employee is in development, operations or security, they are working for the same organization.

    By introducing more automation into the process, gaining a clearer picture of all relevant components and the third-party vendor release cadence, and making security a participant at the beginning of new product development, smoother updates, better security and a productive culture will result.

  • ClickShare Vulnerabilities May Have Been Patched, But They Mask a Much Bigger Problem

    ClickShare Vulnerabilities May Have Been Patched, But They Mask a Much Bigger Problem

    I think we can all recall a time in recent memory where, in a meeting or at a conference, someone has had issues with presentation technology. It happens so often that there is almost an expectation of a clunky experience, at least initially. It stands as no surprise, then, that ClickShare’s seamless app was immediately popular with end-users. For them, there is nothing easier than using a ClickShare application to push a presentation from their laptop, tablet or smartphone over to a big screen or conference room projector.

    Belgian-based digital projection and imaging technology supplier Barco designed their automation platform to work that way, and big business embraced the concept. FutureSource Consulting puts Barco’s market share in conference technology at 29%, with integration into 40% of all Fortune 1,000 companies.

    When researchers from F-Secure revealed in December that the seemingly innocuous automation platform was riddled with security vulnerabilities, it sent shockwaves through the business community. The uncovered security flaws are critical in nature, and could potentially enable any number of malicious activities. 

    Researchers demonstrated how the vulnerabilities could allow remote users to snoop active presentations, create backdoors into secure networks or even configure a spyware distribution server that would infect every user connecting to a Barco device. Suddenly, companies were faced with the prospect of having serious security problems installed directly inside conference rooms and offices throughout their organization. And because of the nature of the vulnerabilities, a single compromised device could support a network-wide breach.

    “An attacker who successfully compromised one unit gains the ability to decrypt as well as produce valid encrypted images for any unit, whether within one family or across families,” wrote F-Secure officials in their report. “Further, such an attacker may gain access to sensitive data at rest such as the configured WiFi PSK and certificates.”

    To its credit, Barco has been extremely proactive in issuing patches and fixes to the vulnerabilities found within its products. Security vendor Tenable recently released a report showing 15 vulnerabilities across eight presentation tools, including Barco. As of February, only Barco has been active in deploying fixes.

    Although some of the Barco vulnerabilities require hardware changes (and these will be a nightmare to deploy, if a firm acts to this degree to secure them at all), many of them can be corrected with software patches. This gives most enterprise users a seemingly good plan to fix their immediate problems, but they are hardly in the clear now. The problems with Barco are just the tip of the iceberg when it comes to dealing with vulnerabilities in well-known hardware and software products.

    The Root of the Problem

    Now that the immediate issues have been resolved, we need to ask how devices with serious security flaws ended up sitting in thousands of conference rooms worldwide, or why they were so poorly designed and programmed in the first place. It’s not like the F-Secure team was uncovering zero-day or previously unknown vulnerabilities. Ten of the flaws discovered in the Barco products were associated with well-known, common vulnerabilities such as code injection attacks. Most already had Common Vulnerabilities and Exposures (CVE) identifications.

    So how did decades-old CVEs get coded, or even hardwired, into modern presentation tools? The only possible answer is that developers either didn’t know about them, or that security was not made a priority as the Barco devices were being designed. Sadly, this is a common situation, and certainly not exclusive to the Barco teams.

    The best time to fix a vulnerability is while an application is being developed, long before it gets sent out to users. The worst (and most expensive) time is after a product has been deployed, or after it’s been exploited by hackers. This can be a hard lesson, and one that Barco will surely learn as its once-impenetrable market share takes a hit following this security fiasco.

    Shifting security fixes back toward the development process isn’t easy, but is necessary in today’s world where even seemingly simple devices like presentation tools are both surprisingly complex, and also networked into everything else. In this environment, security must become an organizational best practice. It doesn’t matter if a company is programming apps for social media or manufacturing smart toasters, security must be considered in every facet of an organization.

    Prioritizing security best practice and making it a shared responsibility is the goal of the DevSecOps movement, where development, security and operations teams work together to code and deploy secure software and products. It requires as much of a change in culture as anything else. The new mindset needs to be that deploying a working product with security vulnerabilities is just as much a failure as creating one that can’t perform its primary function.

    In a healthy DevSecOps environment, anyone touching software should be security-aware, with developers receiving relevant and frequent training to avoid introducing disastrous bugs into their work. If the teams working for Barco had looked at security as a shared responsibility, there is no way that such a large collection of vulnerabilities, including decades-old CVEs, would have made it into their presentation tools.

    The Safe Path Forward

    Nobody wants to be the next Barco, having to explain why well-known security flaws were deployed through their devices to thousands of enterprise networks around the world. To avoid that fate, companies developing software or smart hardware should immediately prioritize security as both a shared responsibility and an organizational best practice. Creating a healthy DevSecOps program will take time and likely also require a shift in culture, but the results will be more than worth the effort. Robust DevSecOps can crush vulnerabilities long before they cause trouble.

    For companies buying products and software, it’s in their best interest to support firms that have embraced DevSecOps. Doing so will go a long way to making sure that the devices and software obtained from them aren’t ticking time bombs waiting to be exploited by increasingly skilled attackers.