devopsy.kinsta.cloud

Tag: devsecops

  • Security Testing: Reducing Resistance to Change in an Agile and DevOps World

    Security Testing: Reducing Resistance to Change in an Agile and DevOps World

    Software development has evolved, but security testing has not. That has to change

    In the bad, old days—which, sadly, many are still living in—security testing was tacked onto the end of the development process. Security testing hasn’t been a feature of software engineering for around 15 years now, since agile supplanted waterfall as the primary development methodology. The old idea of security testing as an independent, external audit, where security folks sit far outside the development process, is ineffective at preventing massive data breaches and ensuring developers have the knowledge required to build secure applications.

    Until the mid-1970s, the concept of desk-checking software was necessary due to the slow turnaround time of punch cards, compilation and batch job testing. Desk-checking and formal verification are the genesis of the security audit. Though software engineering has developed through timesharing, real-time debugging, individual computers for each developer, waterfall, object-oriented programming, rapid application development and, finally, agile and DevOps, security is still stuck in the mid-1970s. Security professionals are not auditors and security audits are not a viable replacement for sound security engineering.

    There is no doubting the need for objective tests along the way, but the construction industry shows us the way here. Any large building project regularly tests random concrete deliveries for compression and tensile strength. While every metaphor breaks down if you push it too far, there is a place for continuous security testing in an agile world. This should take the form of executable tests, rather than reports.

    Modern “unicorn” development is proud of the DevOps culture that allows developers to push code into production many times a day. But in the DevOps deployment model, it’s impossible for traditional security practices to keep up. A typical security testing schedule is every 12 to 18 months if you’re lucky, or never if the app is not considered significant. There could be thousands of untested builds in that time.

    How do we fix this? How do we scale? The security profession must adopt agile and DevOps processes and use the same tools as developers. It is that simple. However, it’s incredibly difficult for many. Historically, security professionals haven’t come from a development background, and so the concept of delivering security tests as source code is at odds with 40 years of penetration testing.

    The first thing that must change is the way organizations receive results. One of the tenets of an early agile methodology called “extreme programming” (XP) is “you ain’t gonna need it” (YAGNI). I posit you “ain’t gonna need” a PDF report. Results should be delivered via APIs, directly into existing development defect trackers, such as Jira or GitHub Issues, or a vulnerability management solution. The worst possible outcome is a 60-page PDF sitting unread in someone’s inbox—or worse, trying to scrape it or manually cut and paste into an Excel spreadsheet. Developers will never see the entire report, as if it is a state secret, and yet they have to fix discovered issues.

    I hear screams in the distance! How’s an internal audit going to verify that security is in place and effective without a PDF report? They can and should look at the results of builds. It is that simple. If developers can demonstrate that every build for the last 12 months passed security unit and security tests, that is a job well-done. No one asks accountants to provide a PDF report of the latest reconciliation as proof that reconciliation is working. The evidence is that the numbers are the same in the online accounting and banking systems. If an auditor wants to produce a cover sheet saying that they randomly sampled build testing results over the last 12 months and assert that the results are a true and correct representation of security effectiveness, good for them.

    Security professionals are not auditors and should not be writing reports. They should be testing software, sharing knowledge and writing tests. Security professionals should be embedded with developers, helping them understand why a security test has failed and discussing solutions, possibly even coding a potential solution. Security professionals can learn about the enterprise and specific application business risks, and the development team can learn how to fix current issues and protect against security failures in the future.

    It’s critical to understand that as executives ponder this change, there will be resistance. The security industry is structured around delivering short-duration, high-skill testing. This type of testing often tests the skill of the assessor and web application firewalls, and not the application itself. Modern security practices—such as the one I lead—have moved to abuse cases, where no web application firewall will protect you. We have offerings and talk with our clients about agile CI/CD pipeline security, but even though what we want to move on to will be utterly obvious to everyone in a year or two, resistance is strong.

    How do you move forward in the interim? Ask your security vendors to deliver proof-of-concept unit or integration security test cases to be run in the build pipeline. Provide source code to your apps so they can write the tests in the same codebase to test every build and allow your developers to maintain these tests.

    In the meantime, review the effectiveness of your PDF-based security program. Challenge your vendors to come up with something that works with your development teams rather than treating them as adversaries.

    — Andrew van der Stock

  • DevSecOps Implementation Process and Road Map – Security at Every Step

    DevSecOps Implementation Process and Road Map – Security at Every Step

    DevSecOps is changing our perspective toward security and is equipping us to deal with its challenges in an intelligible manner. The systematic approach of DevSecOps helps us add value to our business processes while ensuring security.

    Here’s a summary of the key inputs and a recipe for a successful software development project. Implementing DevSecOps with the primary goal of enhancing security requires a step-by-step procedure.

    It requires the unification of culturally disparate teams of Security, Operations, Development and Test for the sole purpose of building a product marked by quality and backed by security.

    The DevSecOps process will require effective planning, design and release, which will be put together with a collaborative toolchain of technologies to bring about a common goal.

    Furthermore, as organizations continue to rely on automated delivery, avenues are created for testing opportunities beyond traditional bugs. In-house experts will be able to identify potential loopholes, design errors and even code weak spots.

    Being able to identify weak spots and flaws well in advance helps organizations maintain a competitive front in the market and trustworthiness before its target audience.

    DevSecOps Implementation Process and Road Map

    DevSecOps Implementation Process and Roadmap

    1) Planning: Planning is the first approach to any task at hand and the core focus of DevSecOps—security—begins from here. In the planning stage, DevSecOps professionals must go beyond creating feature-based descriptions. The focus should also be on security and performance, acceptance test criteria, application interface and functionality and threat-defense models.

    Tech terminology: Acceptance Test Criteria is used by DevSecOps professionals to understand user preferences and behavior to a software application behavior.

    2) Developing: Developers should approach DevSecOps with a “how to do it” approach, rather than a “what to do” approach. It is important for developers to bring together available resources for guidance, have reliable practices and a code review system in place for themselves and for others in the team to follow.

    3) Building: Automated build tools can uplift the whole DevSecOps implementation process tremendously. These tools ensure test-driven development, standards for release artifact generation and utilize tools to ensure the design aspect is in alignment with the team’s coding and security standards through statistic code analysis.

    They can also be used to identify vulnerable libraries being used in your application and replace them with new ones.

    4) Testing: Automated testing in DevSecOps should utilize strong testing practices including front-end, back-end, API, database and passive security testing.

    Tech Terminology: Passive Security Testing is a developmental stage testing where security testing is not conducted directly on the target.

    5) Securing: Traditional testing methods always remain in place in DevSecOps exercise. However, somewhere down the line, there is a tendency to identify issues toward the end of the development process.

    Through advanced practices such as security scanning, we tend to become more aware of the issues and can determine if the threat is a serious one or not.

    6) Deploying: Automated provisioning and deployment can fast-track the development process while making it a more consistent one. Infrastructure-as-code tools can perform the aforementioned audit properties and configurations and ensure secure configurations across the IT infrastructure.

    7) Operating: Regular monitoring and upgrades are the Operations team’s important tasks. DevSecOps teams ensure to deploy infrastructure-as-a-code tools to update and secure the entire organization’s infrastructure in a quick and efficient manner with no scope for human error. Operations personnel have to be especially watchful of zero-day vulnerabilities.

    Tech Terminology: Zero-Day vulnerabilities are a software breach that remains unknown to software productions personnel and can eat away at a computer program and other components such as a network.

    8) Monitoring: Constantly keeping a watch for irregularities in security can save an organization from a breach. Hence, it is essential to implement a strong continuous monitoring program with real-time to keep a track of system performance and identify any exploits in their early stages.

    9) Scaling: Gone are the days when organizations spent precious hours and money on the maintenance of large data centers. With the introduction of virtualization solutions and the cloud, organizations can scale their IT infrastructure or replace it in the event of a threat, which would be impossible to do with a traditional data center.

    10) Adapting: Continuous improvement is key to any organization’s growth. An organization will only be able to achieve the desired growth of it evolves in its practices including DevSecOps practices—security, functionality and performance. Therefore, an organization should adapt to continuous improvement and external changing trends.

    The DevSecOps is in itself a process of innovation that substantially adds value to an organization.

    Point to Remember: Security is everyone’s responsibility.

    — Veritis

  • Fail Fast: How Shifting Security Left Speeds Development

    Fail Fast: How Shifting Security Left Speeds Development

    How DevSecOps can help organizations increase security, move faster and save money

    With developers under constant pressure to create more software in less time, the last thing you need is for your code to fail at the end of the development lifecycle. No developer wants to create inoperable or insecure code.

    We know that most software products reach the market with flaws or vulnerabilities. On average, more than 85 percent of all software applications have at least one vulnerability, and more than half of flaws remain unaddressed for one to three months after first being discovered.

    The sooner a developer can identify, view and correct a flaw, the more efficient it becomes to fix in the software development life cycle (SDLC). That is the underlying philosophy of DevOps. Despite the somewhat negative connotation, failing early in development can be beneficial in deploying software to market more quickly.

    The most advanced organizations today employ a DevSecOps model, which tends to incorporate more frequent security scans, incremental fixes and faster rates of flaw closures into the SDLC. More importantly, it allows security teams to shift left to test software products against security standards earlier in the development process.

    According to Gartner, more than 80 percent of development teams will implement DevSecOps by 2021. In 2017, that number was around 17 percent.

    In Veracode’s latest “State of Software Security” report, we discovered companies that adopt a DevSecOps approach to development are addressing software vulnerabilities more than 11 times faster than companies that use a more traditional software development method. In the process, DevSecOps companies are innovating faster, saving money and becoming more efficient in how they identify and resolve new risks.

    By integrating developers with IT operations and focusing everyone on making better security decisions, DevSecOps can help deliver safer software with greater speed and efficiency.

    Introducing security earlier in the development process creates a sort of blueprint for teams to build within the specifications of major IT regulation and helps reduce risk by fixing vulnerabilities before they can be exploited. Think of it like building an apartment complex according to city codes with inspectors integrated in the construction crew.

    In practice, DevSecOps can add some friction and hinder the development process. Traditional tools for testing code and assessing application security risk simply weren’t built for the speed that DevOps testing requires.

    To make DevSecOps successful, development teams need to start with automated testing tools, as relying on manual processes can’t possibly keep pace with accelerated development timelines. Tools that can be used in an integrated development environment (IDE) are key, as they allow developers to integrate security into their workflow rather than having to launch a new environment whenever they need to test code. Solutions that check for flaws during the coding process enable developers to address vulnerabilities early on when fixes are the most cost-efficient. And because DevSecOps is equally concerned with security when software is in production, development teams need tools for testing applications after release. Development teams, meanwhile, must be comfortable with changing the way they work.

    Business leaders must recognize the importance of integrating security with development and communicate that priority to development teams. New regulations such as the EU General Data Protection Regulation (GDPR), which can fine companies up to 4 percent of their revenue for failing to disclose processes related to data breaches, are now in place. All businesses must be motivated to operate with a security-first mentality that permeates through the business, including within development teams. Veracode data shows that customers taking advantage of DevSecOps’ continuous software delivery are closing their vulnerabilities more quickly than the typical organization.

    DevSecOps doesn’t always require security personnel to be physically involved in the development process. Companies can and should train developers on basic security techniques and offer security resources to help developers become responsible for the security of the software they build.

    As the DevOps movement has unfolded, security-minded organizations have recognized that embedding security design and testing directly into the continuous software delivery cycle of DevOps is necessary. This is the genesis of DevSecOps principles, which offer a balance of speed, flexibility and risk management for organizations that adopt them.

    — Mark Curphey

  • DevOps: Don’t Let Detection Be a Bottleneck for Security

    DevOps: Don’t Let Detection Be a Bottleneck for Security

    AI and automation can help ensure DevOps security doesn’t impact performance

    The world revolves around software and internet-based applications—and speed is crucial. Users have very little patience for delays and will quickly jump to something else if performance lags. Organizations have embraced DevOps and containers in an effort to accelerate development and deployment of software and maintain a competitive edge over rivals. One of the biggest challenges, though, is how to identify vulnerabilities and detect security issues without significantly degrading performance.

    There will always be some impact on performance. You are adding an extra layer of functionality—a layer of security intended to detect and resolve security issues. No matter how fast that detection is, it will still take more time than not having any detection at all. The goal is to implement detection with as little impact on performance as possible. You don’t want detection to be a bottleneck for your cybersecurity efforts, or a drag on performance in general.

    Bridging the Gap Between Speed and Security

    One of the defining characteristics of a cloud-based, containerized, DevOps environment is its dynamic and continuous nature. In an effort to streamline and accelerate business, organizations embrace continuous development, continuous integration and continuous deployment combined with continuous monitoring, continuous testing and continuous improvement—all of which require continuous security.

    Real-time monitoring for suspicious or malicious activity is crucial. The internet doesn’t sleep, and attackers are constantly scanning and probing for vulnerabilities and weak links to exploit in your network and applications.

    Security is important, but not at the expense of productivity. The challenge is how to bridge the gap between speed and security—and ensure you can detect attacks effectively without introducing undue friction. You need balance—security that provides necessary protection without defying the whole point of trying to streamline and accelerate business. In other words, security needs to become a guardrail rather than a roadblock for DevOps.

    Improve Detection with Automation and AI

    Real-time protection is necessary—but not all real-time security solutions are the same. How attacks are detected is as important—or more important—than just detecting them.

    Why? Simple. Attack detection based on signatures or generic patterns such as a core rule set or regular expressions are not customized to recognize threats in the context of the application. For example, with a RASP (runtime application self-protection) solutions, even if the control points are good, the end result will be poor without the right context and detection techniques. This approach is also reactionary and leaves you exposed for some period of time. It is generally ineffective until the signature is developed, and the signature can’t be created until the threat is detected and identified.

    Automation and artificial intelligence (AI) can accelerate the process and provide more effective protection with less friction. An AI-powered platform can learn from stateless traffic and deconstruct application logic to create application-specific rules—and update the rules dynamically without the need for human intervention. Using dynamic, application-specific rules rather than signatures and manual rules can result in efficient detection and an exceptionally low false-positive rate. An automated solution that leverages artificial intelligence also can protect without waiting for signature updates.

    Modern Security for Modern Networks

    The days of periodic scans are long gone. The network architectures and threat landscape today demand constant, real-time protection. Legacy detection techniques are cumbersome and can’t keep pace, but an AI-powered attack detection platform that is automated will be more effective for protecting a dynamic, cloud-based, containerized, DevOps environment.

    — Tony Bradley

  • Study: CISOs Need to Take Charge of DevOps Security

    Study: CISOs Need to Take Charge of DevOps Security

    A new report from CyberArk looks at the complexity that goes into securing emerging DevOps environments, and why CISOs need to take charge to protect them.

    As digital transformation is pushing more enterprises to adopt DevOps to address their needs for better software delivered faster and more frequently, a huge issue lingers over this strategic business shift: security.

    While businesses pay a good deal of lip service to cybersecurity, the rush to churn out new software and update those applications means that security is often skipped in the name of speed and innovation. At the same time, InfoSec is seen as a cumbersome barrier to what the DevOps team is trying to achieve.

    Despite these attitudes, it’s imperative that security is part of DevOps conversations, and it’s the company CISO who needs to lead that charge.

    In a report released last month, CyberArk polled 1,000 CISOs across the globe to assess how to make DevOps more secure and to ensure that the cybersecurity team is talking to the CIO and other executives overseeing the DevOps process to solidify good cybersecurity.

    The report, “Protecting Privileged Access in DevOps and Cloud Environments,” actually skips the more trendy term of DevSecOps in favor of a more holistic approach that bakes the security component into the very beginning of the application development cycle.

    Brian Kelly, the head of Conjur Engineering at CyberArk, believes that the DevSecOps term limits the ability of CISOs to offer ways to secure application development at the beginning of the process and ensure that updates embrace good cybersecurity practices.

    “Some organizations embrace it, while others refuse to use it,” Kelly wrote in an email about the debate over the DevSecOps term. “We do not use the term because it implies that security is a ‘gate’ or ‘phase’ that can be done after development is finished—but before the apps go operational. Security isn’t just a bolt on to DevOps, and this mentality can lead to a lot of broader issues for operation and development teams.”

    This means ensuring security is a part of every DevOps conversation, including making it part of hiring, training, road map creation, feature design, architecture, coding standards, code review practices, continuous integration/continuous delivery (CI/CD), operations, monitoring and maintenance.

    The CyberArk report makes clear that many of the tools needed to make DevOps successful within the business are a tempting target for cybercriminals looking to burrow deeper into the corporate network. For example, cloud access keys—whether for AWS, Microsoft Azure or Google Cloud Platform—can open a wide range of company data for threat actors to steal.

    The Uber data breach of 2016 started when the company’s AWS access keys were compromised.

    Other targets include CI/CD tools for configuration management, including Puppet, Chef and Ansible, as well as tools for running automated tests and builds and this can include Jenkins and Bamboo.

    Another red flag for security teams and CISOs is GitHub, since developers tend to have multiple accounts, and can sometimes mix code from personal and corporate projects. A cyberattack using brute force methods can sometimes leave code exposed. Since many developers cook some secrets into the code, such as database credentials, this can expose company and customer data.

    “[GitHub] hosts most of the world’s code for modern projects (and almost all open source projects) so any security mistake they make will have wide-reaching consequences,” Kelly wrote. “Up until now, they’ve been able to sidestep many issues by just being a hosting provider for repositories and leaving the responsibility to their customers for what they push up there. But they’ve since added more features for collaboration and CI, which naturally make their users want more of a safety net: automated scanning of third-party libraries for CVEs or watching for things like AWS keys being checked in, for example.”

    With all of these difficulties, what can the IT and DevOps teams do to increase security? How can the CISO help make security a central part of the app development process? Kelly offered some practical steps enterprises and their leadership can take:

    • Engage security teams early in the development cycle. This helps identify security issues early in the process.
    • Use a security-policy-as-code approach to have the Dev, Sec and Ops teams communicate efficiently and unambiguously. This means that new applications or microservices would declare their security policy requirements within code. It gets checked into source control and is as much a part of the application’s code as its internal implementation.
    • Decomposing large applications into smaller microservices, each with their own security policy.
    • Reducing the “batch size” of changes as much as possible, enabling the security team to work on a smooth, predictable flow of small items.
    • Getting end-to-end early to mitigate the risk the ongoing upgrades of components and modules.

    At day’s end, while CISOs need to lead the security charge when it comes to application development and delivery. At the same time, DevOps isn’t a fad, and will remain part of the enterprise for a long time. Security leaders need to do some embracing of the trend, too.

    “If CISOs want to remain relevant, they will need to see DevOps as a model that they have to align with, not against,” Kelly wrote. “Recent history shows us that large, org-wide DevOps initiatives rarely get shut down once they start, so a successful CISO will build bridges to the Dev and Ops groups and work with them to apply visibility controls and security oversight in ways that don’t cripple their speed. A failing strategy would be for the CISO to resist that sea change and instead try to be a gatekeeper and hold up inevitable progress. The only progress they’ll likely see will be in the speed of their replacement getting hired.”

    — Scott Ferguson

  • Salt Security Unveils Platform to Secure APIs

    Salt Security Unveils Platform to Secure APIs

    Salt Security, fresh off raising an additional $10 million in funding, announced a platform that promises to advance the state of DevSecOps by making it possible to detect when application programming interfaces (APIs) are being probed by cybercriminals looking for weaknesses to exploit.

    Salt Security CEO Roey Eliyahu said the Salt Security API Protection Platform employs machine learning algorithms to first establish a baseline for how APIs are being invoked across an IT environment. The software-as-a-service (SaaS) platform then monitors activity to surface any anomalous behavior indicative of cybercriminals engaging in reconnaissance of API traffic flows, he said.

    Armed with that analytics, DevOps teams can then prioritize fixes to any potential security hole cybercriminals might be able to exploit. That approach advances DevSecOps because the Salt Security technology makes it possible to feed requests to address those security issues directly into a continuous integration/continuous deployment (CI/CD) platform—critical, he said, because all too often developers are unclear regarding what cybersecurity professionals are asking them to fix whenever a cybersecurity issue arises.

    Eliyahu noted that, in today’s business environment, security has become a major concern. According to the Open Web Application Security Project (OWASP), nine of the top 10 vulnerabilities in its current Top 10 report include an API component. Insecure APIs were ranked as the third most severe threat to cloud computing in 2018 by the Cloud Security Alliance (CSA), and Gartner predicts that by 2022 API abuses will be the most frequent attack vector resulting in data breaches for enterprise web applications.

    The challenge organizations face is each API is unique to each application and the organization that builds them, which means each has unique logic and, by extension unique vulnerabilities, said Eliyahu. Existing cybersecurity tools lack granular understanding of these because they are designed to protect organizations from known attacks. Attacks that target API logic go unnoticed by these tools because they appear to be authenticated use cases, and then employ subtle methods to probe each for unique vulnerabilities, he noted.

    To thwart those attacks, the Salt Security technology automatically discovers all APIs and associated functionality, said Eliyahu. That’s important because it’s not uncommon for organizations to lose track of the many that might have been exposed over the course of an application’s lifetime.

    APIs in general are often overlooked because much of the focus in any organization tends to be on business logic. But as the number of applications and services continue to proliferate across the enterprise, the number of APIs being exposed has increased dramatically. Those numbers will increase more as organizations embrace microservices to build applications that are more easily updated.

    The issue, of course, is how to secure APIs that often are developed and maintained by teams that weren’t involved in the integration of the original application. Because of that issue, API management has emerged as a discipline unto itself within many organizations. The challenge now is finding a way to ensure those APIs are employed as intended, versus becoming an avenue for data exfiltration that no one is aware of until it’s long too late.

    — Mike Vizard

  • IoT, Not People, Now the Weakest Link in Security

    IoT, Not People, Now the Weakest Link in Security

    Do a quick search on “people weakest link” and you’ll see a raft of articles in which cybersecurity experts and computer scientists point to employees or end users as the biggest vulnerability. No doubt, people do silly (or outright abusive) stuff and open the door for a variety of enterprise security problems. Spoiler alert: There’s this technology called the Internet of Things (IoT) and it’s a bigger security risk than people ever were. The new theme of this rapidly changing IoT security story is data integrity.

    Increased cybersecurity risk is due in part to the variety of environments IoT applications touch. Most at-scale IoT deployments use some form of a three-tier architecture, with edge, gateway and cloud components.

    • Edge devices are those connected sensors and actuators touching the real world. They are usually small, low-power devices often running a wireless protocol such as Bluetooth, Thread, ZigBee, Z-Wave, sub-GHz, low power wide area (LPWA) networks, cellular IoT technology, Wi-Fi or other protocol.
    • Gateway devices are hubs that groups of sensors connect with. One big role of the gateway is to translate the various protocols from edge devices into Internet Protocol (IP) for transmission into an enterprise network. Gateways also perform a key role in provisioning edge devices securely. Smartphones running Android or iOS often serve as a gateway for consumer IoT devices. For industrial IoT devices, multiprotocol gateways typically are built on a small form factor computer running a real-time operating system or Linux. Edge computing or fog computing architectures use enhanced gateways for more algorithm processing.
    • Cloud platforms are very familiar to most enterprise developers. In IoT apps, data from the edge arrives for processing, storage and presentation. Algorithms can run on a server cluster or in a distributed computing framework such as Hadoop or Apache Spark. Business intelligence and predictive and prescriptive analytics also reside in the cloud.

    In our practice, we see many IoT cybersecurity issues that can be mitigated with proper attention to two areas. The first is shutting down simplistic endpoint attacks by using basic connected device security measures. Avoid edge devices that ship with a well-known default password or PIN—compromising those defaults can be as easy as a battery pull and a factory reset. If a device uses encryption, make sure it doesn’t use a hardcoded key that, if cracked, compromises an entire family. Look for edge devices using over-the-air (OTA) programming allowing for security updates over a long life cycle. As more device developers gain IoT security experience and provide the right features, closing these basic weakest links is easy.

    Now, for the more startling weakest link. When the IoT application runs, is the data any good? According to a just-released survey of 950 IT and business decision-makers, only about 48 percent of companies are confident they can detect an IoT security breach. (BTW, don’t get me started on blockchain; it’s one tool, not a panacea.) A lot can happen before your people get involved. By then, it may be too late.

    Data integrity needs constant monitoring during at-scale IoT deployment, not just during pilot. An easy way into an unprotected IoT network is to add an unauthorized edge device at a gateway, then use it to access other devices. Gaps in end-to-end encryption are also easy exploits. Untrustworthy public cloud elements are also bad news—a big reason we recommend hybrid cloud architecture. A private cloud layer gives you more control over algorithm performance and data stream security. Presentation and archiving can be left to a public cloud layer.

    Bad data can come from either a compromised or faulty device. It propagates quickly across a system, and when an unwitting user at the presentation layer runs a business intelligence tool on it, the bad data could cause issues. How do teams hunt down vulnerabilities and faults that lead to corrupted data and results?

    • Hire a penetration tester, preferably a contractor removed from your day-to-day development who can objectively assess your architecture during pilot and reassess it during deployment.
    • Ensure your architecture can tolerate edge device or gateway failures without ripple effects in algorithms; in other words, protect the application from prolonged operation on bad data streams.
    • Before turning AI loose on automated decision-making, consider an AI-based IoT security analytics tool to spot anomalies and quickly bring people into the loop.
    • Retarget at least part of your cybersecurity experts to ongoing data integrity efforts and help them stay abreast of IoT technology and trends.

    This all sounds like a good job for DevOps, doesn’t it? You know what to do about people; now you’ll need to work magic with devices. The long-held security axiom that people are the weakest link is no longer true when IoT applications run unattended all the way to presentation. There are a few exceptions when people have more interaction at the edge, particularly in the medical device arena. Generally, we’ll see bigger and bigger IoT applications with more data, more processing and less interaction with people.

    If someone on the IoT says there’s a security hole you can drive a truck through, they may mean it literally. Data integrity measures will be critical for DevOps teams moving forward. Do you agree? What types of data integrity issues are you seeing in IoT applications?

    — Don Dingee

  • How to Turn Your DevSecOps Shift into Your ‘Pixar Moment’

    How to Turn Your DevSecOps Shift into Your ‘Pixar Moment’

    If you have worked in security as long as I have, you have seen that vulnerabilities persist, despite years of attempts to fix them without changing how the organization operates. One of my all-time favorite leadership quotes comes from the first stockholder meeting after Robert Iger, the CEO of Disney, bought Pixar. “The riskiest thing we can do is just maintain the status quo,” he said. This quote has stuck with me and I feel that the shift to DevSecOps can be many teams’ “Pixar moment.”

    In recent years, there has been a push to shift to a DevSecOps model that has the potential to make a drastic change in the way an organization operates. But unless these shifts are planned well, they often fall apart without having made a meaningful impact.

    The root cause is often the inability or unwillingness to do the in-depth planning and testing required to make sure everything will move to a DevSecOps smoothly. The failure to plan leads to underwhelming returns and low morale with the organization will slowly slide back to the old “status quo.”

    Moving to DevSecOps is often more about changing an organization’s cultural identity than any technical changes. I’ve have seen it happen successfully in several places. Here’s what they had in common:

    They Defined, Discussed and Documented the Old and New Build Process

    A successful move to an end-to-end CI/CD system normally starts with one thing: a whiteboard. Organizations bring representatives from every existing team (systems, networking, security, development) to form the new DevSecOps team and build an end-to-end diagram of what it takes to build and maintain the system immediately. For many, this meeting is often the first time they have seen a true end-to-end view of the system.

    Then the new team commits resources to discuss the standards and policies they need and want the new system to be built to. They discuss methodologies, deployment schedules, SLAs, business requirements and overall system architecture and security. This is where the team must come to an agreement on the right way to build and where the security team is likely to see their first big win on improving the “status quo.”

    This round ends with something that no one on the new team will likely enjoy, but is crucial to the shift moving forward: a document of all of the decisions made that can be easily shared within their organization.

    They Built a Strong Team and Platform

    The next step is normally everyone’s favorite part—at least at the start. The team gets to walk into a greenfield environment and move one application to their new DevSecOps flow. Essentially, each team member has the opportunity to bring their ideas and thoughts about modern security, architecture and deployment processes and see if they can apply them. However, the honeymoon period of this process often ends quickly and becomes the most challenging segment of the whole process. The switch from theory to practice isn’t as clear as many DevSecOps teams think, and it’s common for teams to struggle while working with new products with which they likely have not had much organizational experience.

    Buy-in from leadership is critically important here and without it, these projects can quickly go awry. I have heard executives complain that their DevSecOps team is “just playing around,” “wasting company resources” or “learning skills that will just let them get a better job somewhere” when a new system seems to take longer to be built than originally expected. Supporting this team throughout the build process is one of the most important leadership roles in a move to DevSecOps and plays a crucial part in aiding this team and reinforcing its culture within your company.

    Continual Incremental Improvements

    Once you have your first DevSecOps flow created, it is important to remember that you are not done, as you would be in a traditional build model. Of course, you want to celebrate this success, but you also need to start answering these questions:

    • What can we do to increase the deployment frequency and speed?
    • Can we do anything to lower the failure rate of the new releases?
    • Are there any steps that could be more automated?

    If you continually ask and answer these questions, you will never be done, but you will continue to make incremental improvements that will help your organization become more agile over time.

    Rinse and Repeat

    Once you have built your first DevSecOps workflow, you now have a good baseline on what to do (and not to do) when you move your next application to this model. Hopefully, you’ll be ready to move the DevSecOp culture that has taken hold in your organization to the next team.

    — Jerry Gamblin

  • Applying DevSecOps to Address Cloud Security Challenges

    Applying DevSecOps to Address Cloud Security Challenges

    Driven by the encouragement from 2018 progress, cloud technology is poised to be even bigger in 2019. However, one major hurdle continues to haunt the cloud trend: security.

    An overwhelming number of firms in the IT industry are preparing for cloud adoption, yet security continues to be a big question for many of them. Early DevOps adopters faced a similar challenge in their early stages of DevOps implementation. They relied on a wide variety of DevOps tools to address their issue completely.

    Today, however, DevSecOps is making a big difference in the IT industry, including security and ensuring a seamless software development life cycle (SDLC).

    Breaking the regular trend of having security as a separate process, DevSecOps calls for security integration across all stages of the software process chain, addressing security concerns at the very first instance of every stage.

    The same DevSecOps now comes as a savior for cloud, too.

    Applying DevSecOps to Cloud

    Last year saw the cloud market taking a new position in the IT industry, driven by the wide penetration of leading cloud computing service providers: Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), Oracle Cloud and IBM Cloud, among others.

    To stay relevant in today’s market, many IT firms have begun their efforts to achieve high and highly scalable performance with all-round digital transformation.

    Yet, security limitations associated with cloud continues to be a concern many of these organizations. DevSecOps principles can help. Many research reports show that the majority of firms working on the cloud have high reliability on DevSecOps tools and principles for improved agility and high reliability.

    DevSecOps approach to cloud security requires detailed planning that might even demand cultural change in an IT environment, especially for security automation and configuration of cloud assets.

    The planning requires security teams to:

    • Collaborate with development teams as they move code to cloud alongside close monitoring of quality in the production cycle.
    • Work with the quality analysis and development teams in deciding qualifier and parameter aspects required for code promotion.

    Overall, DevSecOps principles offer security advantage along with software agility and high reliability across the life cycle.

    Implementing DevSecOps in Cloud

    Following six factors decide the success of DevSecOps implementation in a cloud environment:

    DevSecOps implementation in Cloud environment

    1. Code Analysis – Continuous improvements to software mean revisiting code, which also reflects in code analysis, quality assurance and delivery cycles.
    2. Automated Testing – Automated testing minimizes efforts and also saves time. As a key aspect of DevSecOps process, automated testing makes the testing process easier through easy execution of repeatable cases.
    3. Change Management – Linking teams and making them aware of each other’s operations, wherever required, is an important aspect of change management. Keeping developers informed about security-related activities helps in timely address of existing and possible vulnerabilities.
    4. Compliance Monitoring – Compliance continues to play a key role in an organization’s growth path as part of corporate governance. Regulations help in the creation of code and also in modifying the source code. This helps in real time at times of audit.
    5. Threat Investigation –  Threat investigation is important to defining the security readiness of any organization. It’s important for organizations to have a close and continuous watch on discovering possible threats, regular security scans and code reviews to address security challenges.
    6. Personnel Training – Holding hands-on training sessions and certification courses build the company’s strength, equipping teams with appropriate domain knowledge.

    The above-mentioned six steps act as building blocks for implementing DevSecOps strategy in cloud. What’s next? The implementation part: Get DevSecOps to cloud.

    — Veritis

  • DevOps Chat: Identity Management with ForgeRock’s Peter Barker

    DevOps Chat: Identity Management with ForgeRock’s Peter Barker

    Two megatrends for 2019 and beyond is scale and automation. The identity management space is a perfect example. Considering all of the IP-enabled devices (machines) coming online and the billions of people and their identities, managing these billions and billions takes systems that will redefine scale and, almost by definition, have to be automated.

    Enter ForgeRock. The company is a leader in identity management for both consumer brands, IoT devices and more. In this DevOps Chat, we speak with Peter Barker, chief product officer, about the challenges to scaling at this level and how important identity management is.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. Got a nice chat lined up for today. I’m joined by Peter Barker, who’s the chief product officer at ForgeRock. Peter, welcome to DevOps Chat.

    Peter Barker: Hey, Alan, good to be here.

    Shimel: Thank you. Thank you for joining with us. So, Peter, let’s jump right into things ’cause time’s limited. ForgeRock is a company that I think a lot of people have probably heard of, but I don’t know if people are solid, you know, as a rock, on what exactly they do, so why don’t we start with that? Give us just a quick kind of “Who’s ForgeRock?”

    Barker: Yeah, so ForgeRock is recognized as the most visionary and market-leading identity and access management platform, and we serve the largest logos on the planet, solving a variety of use cases. We provide simple and comprehensive solutions for brands to serve their customers, with identity and access, to deepen their relationships with those customers. And as well to provide access management and identity solutions for employee and partner use cases as well, to really allow better productivity and connectivity in the employee base.

    Shimel: Excellent. And, Peter, I always like to ask my guest to give our audience a sense of your own personal journey. How did you come to be chief product office at ForgeRock?

    Barker: Yeah, it’s a great question and I think back on this journey I’ve been on for the last 25-plus years of my career. I originally started out on the customer side of the house in IT, doing systems development, application development for Kinko’s and FedEx, who acquired Kinko’s, but, later, the last 15 years, I’ve been in product companies, focused on enterprise software and security solutions. And that spanned mobile and mobile security, with good technology. I was at Oracle as well, running their identity and security business for a few years. And then, most recently, now with ForgeRock, over the last year, as their chief product officer.

    Shimel: Excellent. So, Peter, you spoke a little bit about ForgeRock’s mission and what’s going on, but one of the things that – I mean, it’s almost intimidating when we think about it. It’s just the sheer scale. You know, we look at ForgeRock and, I mean, you guys are doing everything from managing and working on identities of consumers coming to large consumer brand websites and applications, through to IoT devices. I mean, not to get all _____ and honest, but it’s billions and billions, right? I mean, it almost seems like an impossible job. How do you chunk that up? How do you go Agile on it? How do we manage it?

    Barker: Yeah, no, it’s – yeah, first of all, you’re absolutely correct. The world of identity, digital identity, is just exploding. It used to be, in the early days of this industry, it was around modeling identities of your employees and providing access and having governance around that access, but, as the world has shifted to consumer and business transformation around digital and having to know your customer across your digital channels, then scale started to explode in that direction because you have millions of consumers versus just thousands of employees.

    And now, in the world of things, where you have this entirely new economy that’s emerging, where things are interacting with the world on your behalf or with you, whether it’s smart devices, smart cars, smart payments, smart everything and the gig economy, it means that identity systems have to model the identities of all of those objects that are interacting in this new world we find ourselves in. And that is causing a massive need for scale.

    And, at ForgeRock, it’s been a really rich heritage and history for us to provide massive scale in our products. And we are, today, already solving some of the most demanding use cases globally, around scale and serving customers in this new digital economy.

    Shimel: A hundred percent. So let’s try to – Peter, you probably – I mean, as part of your responsibilities at ForgeRock, you probably have some metrics to put around this. Can you volunteer a little bit without divulging any _____ _____ –

    Barker: Yeah, for sure. I mean, right now, some of our largest customers are already scaled into the hundreds of millions of consumers and associated devices with those people. We have use cases defined right now with a lot of these customers that are pushing north of the billion-user mark – we’re proving that out in our labs – but, as we know, to meet the demands of scale, it really requires a new approach to the software deployment and how software supports the scale needs and becoming much more elastic and on-demand, as well as horizontally scalable, because it’s the only way that really, truly will continue to serve this need, as it continues to grow.

    Shimel: Sure. You know, Peter, I had an interesting conversation this morning with a CEO founder of an Israeli-based startup around AI. And what he was saying is the kinds of scale issues that you’re tackling at ForgeRock, it’s almost too big for the human mind to wrap around. Right? I mean, let alone at the speed. I mean, humans just can’t operate at that speed to conquer that scale. We just – it’s almost as if you need to invent or implement some sort of AI, machine learning, whatever you wanna call it, intelligence, that allows you to operate at that scale. And is that something ForgeRock is kind of building in, do you think, or is it still –

    Barker: Yeah.

    Shimel: Go ahead.

    Barker: Yeah, definitely. And we have a framework in our product called “Intelligent Authentication,” and it’s designed exactly to do what you’re describing, which is enabling our customers to continue to not only meet the current needs of scale, but the customers, they want to make the authentication and authorization function of their architecture be much more adaptive, much smarter, much more dynamic, to a conditional and contextual world that may exist.

    And, for example, our customers think about security and fraud pretty interchangeably. And if you just think about the scale problem around fraudulent activity, so, if you look at these large brands with hundreds of millions of consumers who they’re trying to provide services to, of course, there’s always some element of fraud that goes along with being in that type of business. And so they have to put in some very complicated algorithms and logic and what have you to continuously be evaluating whether a transaction that’s attempting to happen is actually fraudulent or, on the other hand, maybe it’s something going on from a malicious actor perspective, who’s doing something around security or attempting to breach.

    And so this is causing the sophistication of the techniques being used to go after these problems to really continue to elevate. AI and ML is a big part of that. Being able to integrate multiple services, who are all providing these functions into, essentially, a fabric that is evaluating the risk that’s occurring, and being able to do that at massive scale is how our customers are looking at this and they’re demanding requirements around that.

    And our Intelligent Authentication framework in our product really enables that to happen. We have the scale in the core engine. We have the framework to allow our customers to create these very sophisticated approaches to dealing with these problems that they’re dealing with, out there in the Wild West of their businesses.

    Shimel: Sure. Excellent. So, Peter, it’s December. We’re starting to look towards next year and everybody and their mother-in-law has a prediction and an opinion about what this next year’s gonna hold for us. What do you – if you had to make your best guess and place a bet, what do you think the big story is for ForgeRock and the whole identity community, in the next year or short term? Let’s say 18 months.

    Barker: Yeah, so I’ll just cover a few things that I think inform my answer. First of all, there’s some very interesting challenges that our customers are facing, that apply broadly within the market. First is really a skills gap. So, a few years ago, I started tracking a stat around cybersecurity job openings and how many of those are going unfilled and how many are projected to stay unfilled in the future. And the most recent estimate is that, by 2021, 3-and-a-half million cybersecurity jobs are going to be unfilled.

    And, if you think about that, that’s just a massive challenge for enterprises who are gonna have to continue to deal with and advance their security programs and their security capabilities, when there is a labor shortage, in essence, in the market. And what that’s requiring is vendors to provide solutions that increasingly automate their security program and to provide the security solutions in a much more automated way, so that’s one big area.

    The other is obviously cloud. You know, the most recent prediction by Gartner is that 75 percent of organizations, by 2020, will be running in multi-cloud or hybrid cloud environment, so that just keeps on marching on and forward, as we go on in time. And then, finally, our customers continue to wrestle with security and ease, where that balance between consumer convenience and security is always – it’s very delicate and it’s something that our customers are always trying to find the right balance for. And so they’re increasingly looking for solutions that both increase security but also increase the convenience for consumers.

    And so what all of that is really driving, from a prediction standpoint, over the next 12, 18 months, is our customers, they have many of the features that they really need right now and today. What they’re looking for, increasingly, is solutions to solve those problems. And so we at ForgeRock continue to innovate and deliver new, powerful capability, like Intelligent Authentication, as I talked about earlier, but the big, new element of the equation that customers have been looking for is “How can they transform their software delivery model to much more DevOps? How do they transform their identity program to be much more multi-cloud and multi-cloud approach, where they can be protecting workloads no matter where they are? And how can they do that in an environment where they have less people, less skilled people available to do the job and to do it in a much more automated way?”

    So we, on November 30th, we released a big, new release of our software, Release 6.5, which really addresses these three key things that we’re seeing with our customers. With that release, we’re now able to allow customers to dramatically increase their productivity and their competitive advantage and reducing their cost by deploying our software in these new methodologies.

    We’ve begun surveying our customers and, right now, the consensus is that customers can save as much as 25 percent on their implementation cost of software just by adopting our next release, which is a dramatic improvement over what they’ve been seeing before. And this release allows them, by providing some very simple cloud installation packages, to rapidly deploy production-ready software into a multi-cloud environment, in minutes, supporting hundreds of millions of identities. And so we’re just really excited and customers have been receiving this release very well ’cause it’s solving so many of these challenges that I talked about.

    Shimel: Absolutely. Absolutely. Peter, I know ForgeRock recently came out with some new announcements around product and so forth. Why don’t you share with us a little bit?

    Barker: Yeah. So I think, just continuing on with what I mentioned just a moment ago on Release 6.5, what we’ve done to really support the new deployment model that we’re providing to our customers is we’re giving our customers turnkey, complete DevOps-capable software to run in multi-cloud environment. And we’re providing not just images for our customers, but we’re providing all of the artifacts necessary to really do this successfully.

    That includes – we’ve standardized in Kubernetes for orchestration. We provide our customers the Helm’s Charts. We provide our customers not only that, we provide the reference architecture. We provide the reference configuration for them. We also do performance benchmarking and not only do the performance benchmarking but give our customers the performance testing tools and methodologies so that they can integrate that into the DevOps pipeline as well.

    And, finally, we give our customers all of the cost profiles of these various cloud providers – AWS, Azure, Google Cloud, and Red Hat, OpenShift are the environments that we’re supporting with this release. We’re dramatically accelerating what it takes for a customer to deploy these platforms to support the mega-scale requirements that we talked about earlier on this call.

    And the other thing we announced is that we have now surpassed 50 strategic partners in our trust network partner ecosystem. And what this does is allows customers to rapidly integrate some very innovative solutions around strong authentication or biometrics or identity proofing or risk analysis or fraud detection into their programs very rapidly because we’ve already pre-integrated, pre-certified, and pre-tested that they’re gonna work for our customers. So a very exciting release for us, here at ForgeRock, and, again, just having some tremendous response from customers on it.

    Shimel: Very cool. Excellent. Excellent. So, Peter, I think, when we started, I mentioned to you, once we start talking shop, the time goes. And we’re about out of time already, but I’m gonna let you have the last word. So I think we’ve educated some people; we’ve opened some eyes; we’ve talked about sorta what the issues, challenges are; and I’m sure there’re people listening saying, “I’m dealing with this challenge. I need this solution.” What’s the takeaway here? What’s the one thing people, if they’re gonna learn one thing, what do they need to remember out of this?

    Barker: Yeah, I think the one thing I would really encourage the listeners to think about, when it comes to identity, is, for employee identity, that’s a space that’s been very well supported and served for a long time now. But what we’ve seen is, as enterprises and brands are transforming their businesses to digital, they’ve taken identity – some have had good forethought around identity and really have put the necessary identity platform in place to support their transformation, but many have just sorta run ahead on their digitization. And they’re starting to discover that the way in which they’re supporting their customers – the customer journeys, in their digital channels, is just not seamless, and it’s because they didn’t think about the identity challenges that they’d be facing.

    And so the takeaway I’d really encourage is I think almost all brands on the planet, at this point, are in some stage of journey around digitization, digital transformation, business transformation to the new economy. And really take a look strongly at the need to bring in an identity platform to really support that because, if you don’t, you’ll find quickly that you’ll be underserving your customer experiences and your customer journeys. And, in this new world, customers really vote with their feet in the digital world, in terms of brands that they’re doing business with. And so we highly encourage folks to take a look at this.

    Shimel: Excellent. Peter Barker, chief product officer, ForgeRock, thanks for being our guest on this episode of DevOps Chat. Continued success with ForgeRock and we’ll have to have you back on soon to check in on the progress, but, in the meantime, keep us safe out there.

    Barker: I look forward to it, Alan, and thanks for having me today.

    Shimel: All righty. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel