Category: IT Security

  • Live Fireside Chat with Christopher Krebs: How to Combat Disinformation

    Live Fireside Chat with Christopher Krebs: How to Combat Disinformation

    We live in a digital world where most information is now found online. This makes it increasingly difficult to verify the veracity of information. Threat actors have been taking advantage of the digital landscape to spread disinformation, propaganda and conspiracy theories to manipulate the public and sow doubt, discord and chaos. How can we distinguish between fact and opinion, truth and supposition? How can we spot fake news and tackle disinformation?

    Former Director of the Department of Homeland’s Cybersecurity and Infrastructure Security Agency (CISA) and Co-Founder of Krebs Stamos Group, Christopher Krebs, will be speaking about disinformation at this year’s DevOps Connect: DevSecOps on May 19 at 12:00 p.m. EDT. During his keynote session, Krebs will explain what disinformation is, how to recognize fake news and the challenges disinformation poses to cybersecurity teams. He will reveal effective ways to combat disinformation, and how public and private partnerships can help. Krebs will also be answering questions from the audience during the live Q&A session.

    Krebs is a founding partner of the Krebs Stamos Group, and previously served as the first director of the federal CISA for two years. Before that, he served in various roles at the Department of Homeland Security (DHS), responsible for a range of cybersecurity, critical infrastructure and national resilience issues. He has also directed U.S. cybersecurity policy for Microsoft and advised industry and government clients on complex cybersecurity and business risk matters while serving in positions with Obsidian Analysis and Dutko Consulting.

    DevOps Connect: DevSecOps has been part of the RSA Conference for six years in a row. This year, the main focus of the event is on “Securing the Cloud Native World.” Krebs has joined a stellar lineup of DevOps, cybersecurity and IT thought leaders as the DevOps Connect 2021 featured keynote speaker. Attend his live session, “Disinformation: As Dangerous as Cyber and Physical Threats,” and check out all the other breakout sessions to learn more about cloud security, DevSecOps, cybersecurity threats—such as disinformation—and more.

    For more information and to register for free, visit the DevOps Connect 2021 website. Save your spot today and learn how to better secure, monitor and maintain the security of your systems.

  • Solving Cloud-Native Challenges in the Rush to the Cloud

    Solving Cloud-Native Challenges in the Rush to the Cloud

    The shift to cloud-native environments away from traditional data center infrastructures continues unabated, but security and complexity challenges remain a struggle for DevOps teams.

    These were two of the main takeaways in a survey and analyst report published by the IT consultancy firm Flexera. 

    The survey, based on the responses of 750 IT professionals, revealed that 92% of the organizations represented in the survey have a multi-cloud strategy, 80% have a hybrid cloud strategy and only a minority (45%) have integrated data between cloud environments.

    The top challenges, according to the survey results, are:

    • security (81%)
    • managing cloud spending (79%)
    • governance, lack of resources/expertise and compliance (75%)
    • comprehending cost implications of software licenses (55%).

    The solution for these challenges largely involves — in addition to implementing the right DevOps culture and practices — adoption of the right tools and platforms, especially for security. However, first-generation cloud-cost management tools “simply are not cutting it” for modern architectures, said Asim Razzaq, CEO of Yotascale, which offers a cloud resource optimization platform.

    “Today’s modern architectures are dynamic, and ownership is transient and not always well-defined. The greatest strength of containers and Kubernetes is the ability to scale on-demand and share cloud resources among multiple applications,” said Razzaq. “Tracking cloud costs in modern architecture requires a strong ability to automate cost attribution — or tag management — for those dynamic resources, and the ability to understand usage at the application level, even for containers that are sharing resource instances.”

    First-generation cloud management tools are, in this way, unable to provide the information DevOps teams require to understand how to automate cost attribution for modern architectures, said Razzaq.

    “[DevOps teams] can’t break down costs into any level of meaningful detail for engineering and finance teams to digest and act upon,” said Razzaq. “Conversely, newer approaches that are focused on Kubernetes cost management lack the ability to understand and break down the costs of non-cloud-native workloads.”

    Indeed, tools are often frustrating to engineering teams because of their static custom reporting, broad and generalized recommendations and no effective workflow for effective collaboration between finance and engineering, Razzaq said.

    “The biggest source of frustration is the inability to drill down and manage costs in a way that matches the way that these teams do business. There may be 10 teams, each with five production applications running in the cloud, for a particular account,” Razzaq said. “Engineers need to see, at the application level, what their resource utilization, costs and cost anomalies are in order to make the best cost/performance decisions for their applications. Without that, they’re flying blind; having to defend their cloud usage without any supporting data.”

    As an example, a misconfigured Kubernetes cluster can “cause a massive spike in costs,” Razzaq explained. “Without detailed cost and utilization reporting at the team and application level, an engineer can spend weeks digging through spreadsheets and logs trying to track down the source of the anomaly. That’s weeks of their time that they aren’t [using to] be productive on new features.”

    cloud-native

    Razzaq said there are a number of solutions DevOps teams can adopt to address these issues, including automated cost attribution and tag management, actionable recommendations and comprehensive observability capabilities.

    Automated cost attribution and tag management “is the foundation of accurate and detailed cloud cost management,” said Razzaq. “Engineers need tools to help them set tag management policies, identify untagged instances and update tags quickly and easily in their cloud environment,” he said. “With this in place, cloud-native workloads can be automatically tagged as they are dynamically created, ensuring that cloud costs are always clearly attributed to the right teams and applications.”

    Actionable recommendations at the cloud-instance level with closed-loop feedback also are an important process “so that engineers can see exactly why the recommendation is being made, and what the cost impact will be of taking that action,” Razzaq said. “The ability to provide feedback on the recommendation and dismiss recommendations that don’t align with business needs ensures that new recommendations are relevant,” Razzaq added.

    Finally, tools that provide a unified view of both cloud-native and traditional workloads that have been shifted to the cloud help to ensure “that engineering and finance have a single source of truth for their cloud costs that enables them to make smarter decisions for their business,” Razzaq said. 

     

  • 4 Ways SASE Fuels DevOps Productivity

    4 Ways SASE Fuels DevOps Productivity

    Many enterprises are adopting secure access service edge (SASE) solutions as part of their digital transformation efforts. SASE, in a nutshell, merges together SD-WAN and security stacks to deliver secure networking and improved WAN performance, making it a logical choice for cloud-enabled businesses going through the throes of digital transformation. However, SASE offers other benefits, which may be of particular interest to DevOps teams.

    Let’s take a look at four ways SASE can enhance the productivity of DevOps teams.

    Reducing Collaboration Challenges

    SASE reduces the challenges associated with team collaboration. SASE, by design, integrates WAN optimization with cybersecurity. Today’s DevOps teams need to work together, despite being physically separated, and must have reliable, secure connectivity amongst the team. “DevOps are all about time-to-market, and DevOps teams are looking for ways to shorten their  CI/CD cycles. A critical part of that process is reducing their dependency on the networking and the security teams,” said Boaz Avigad, director of product marketing, CATO Networks. “Since SASE solutions already provide optimized performance and robust security, DevOps [teams] are free from waiting for infrastructure teams to provision the necessary resources. SASE provides DevOps the control and operational cadence they need without compromising performance or security.”

    SASE Improves Networking

    SASE improves overall network performance with integrated load balancing and failover capabilities. DevOps teams cannot afford to lose connectivity, especially when rolling out new iterations of software or resolving bugs. “For DevOps teams, fast and reliable application performance is critical,” said Avigad. “SASE architectures free DevOps [teams] from worrying about the infrastructure by connecting all the company’s edges, data centers, mobile users and cloud resources, with the same self-healing, secure and fully optimized global network. Should a line fail or a route become congested, SASE automatically switches to an alternate path.”

    Better Security Built In

    SASE helps to secure DevOps projects with native cybersecurity capabilities. When properly implemented, SASE integrates numerous security technologies directly into the network stack. “DevOps teams worry about information interception and protecting their applications from threats. All security services share a single, unified context, improving insight and closing the gaps in legacy security architectures; gaps attackers often exploit,” said Avigad. “SASE not only includes NGFW, IPS, SWG, AV and MDR services, it also converges them together into a single-pass architecture.”

    SASE Removes DevSecOps Burdens

    SASE secures internal applications, along with the interactions with those applications, which in turn helps to reduce the burdens on DevSecOps team members. Applications that run over SASE/SD-WANs are further secured by zero-trust network access (ZTNA) and software-defined perimeter (SDP), technologies that help to keep all interactions between an endpoint and an application secure. “Many proprietary applications are too sensitive to run over the public internet. SASE protects those applications by obfuscating traffic, protecting all entry points with a NGFW and restricting access with its zero-trust architecture,” said Avigad. “All internal application traffic is also continuously inspected for threats.”

    Adopting SASE for DevOps teams is beginning to make a lot of sense. The technology addresses many of the pain points that DevOps teams experience as businesses drive toward digital transformation. What’s more, the security benefits offered bring forth additional productivity, while also unifying the security stack. 

  • How To Address DevSecOps Skills Shortages

    How To Address DevSecOps Skills Shortages

    “If it’s scarce, it drives the price up,” said McAfee director of systems engineering Sahba Idelkhani. And DevSecOps talent is scarce, and expensive.

    Restrictions on international travel are having an effect on immigration in some countries, notably Australia. But there’s practically nothing employers can do about that.

    But some aspects of the supposed skills shortage are, in part, self-imposed. One example is recruitment ads that specify “5+ years’ experience required” (or something similar) when that level of experience is only a desirable characteristic.

    Such practices don’t just restrict the field of candidates for that particular vacancy, they also make it hard to find entry-level positions. If candidates can’t get a foot in the door, how can they gain the experience that employers say they want?

    DevSecOps Change is Needed

    Idelkhani suggests that organizations need to change their hiring practices and put more effort into reskilling existing employees.

    In particular, if you’re looking for DevSecOps people, he suggests it’s better to teach developers about security than it is to bring security specialists (who are also in short supply) up to speed about development. The result is less rework, reduced risk and shorter development timelines.

    However, there is a risk that security specialists will tell developers what they did wrong. Proactively educating developers about security is a more productive approach.

    Cloud Academy is one of many sources for online security training courses and includes hands-on labs, sometimes involving the same tools that criminals use to breach security. Other tips Idelkhani offered include adopting a “build secure” mindset to reduce the security effort needed after systems have been created.

    A similar perspective can be applied to entry-level positions.

    Idelkhani has hired new graduates, even though it requires effort to guide and train them to the point of being productive.

    He has even adopted this approach with experienced people that have no background in security, including a former CTO and mobile developers and a pre-sales engineer.

    Revamp job descriptions so more people can apply, urges Idelkhani, as aptitude and skill are more important than specific experience, which can be taught.

    For example, instead of a large financial services organization recruiting someone with experience in incident response for cloud systems, it would probably be better to hire an incident responder and then sponsor their cloud training, he suggests.

    Furthermore, a diversity program increases the supply of candidates, quite apart from the other benefits it may bring.

    DevSecOps Training

    Employers sometimes suggest training is a waste of time and money because people simply take their new skills elsewhere in search of higher pay.

    But Idelkhani reports that his staff turnover has, in fact, fallen over the last three years, and no one has left after being trained.

    He puts this down to establishing an “emotional connection” between employee and employer, at least in part.

    However, organizations do have to accept the need to pay people what they are worth as they master new skills. But standard HR practices don’t suit skills development situations, he warns.

    People usually won’t move from their current role or company for a 10% to 20% pay raise, Idelkhani said, but would be more willing to do so for the 200% to 300% increase that comes from being considered an accomplished worker rather than a mere trainee.

    At McAfee, he is able to argue for ‘pay for value’ raises for his team; that task is generally harder at larger organizations, he said.

    “It needs a rethink [of] HR practices,” he added.

    Planning

    Substantial raises tend to require approval from higher up in the hierarchy, and that requires a clear justification for the increase. He suggests this should be done in terms of the capabilities that are being built, not based on the numbers alone.

    Managers should look at the skills they are going to need in order to deliver on the business’s strategic goals and plans, and decide how best they can be obtained. An expected DevSecOps vacancy might best be addressed by hiring a cloud developer and training them in the necessary security skills, or by retraining a person with potential who is already on the payroll.

    “It’s a long-term process,” though, that requires a lot of management effort, Idelkhani said. Using this method means identifying people’s interests and skills, aligning them with company goals, identifying the skills gaps and then developing those needed skills. This requires a training budget and getting one approved means having clear plans.

    But once you have shown the value of this approach, senior management is less likely to question it in the future.

  • 42Crunch API Security Platform Now Available On-Premises

    42Crunch API Security Platform Now Available On-Premises

    42Crunch has announced that the scanning tools it provides to enable DevOps teams to secure application programming interfaces (APIs) can now be deployed in on-premises IT deployments.

    Previously only available as a cloud service, the 42Crunch API Security Platform has also been updated to provide expanded support for the OpenAPI specification for REST interfaces defined by the OASIS standards body.

    Finally, the 42Crunch API Security platform now allows IT teams to share collections of APIs among specific teams and users with different levels of access in addition to providing integration with third-party identity management platforms.

    Dmitry Sotnikov, chief product officer for 42Crunch, said the on-premises edition of the API scanning platform will make it possible for IT organizations, including those that require all the platforms they run to be deployed in an IT environment, to exercise more control over and extend their DevSecOps workflows to include scans of APIs.

    Cybercriminals are increasingly targeting insecure APIs because they potentially provide access to a trove of data, Sotnikov noted. Those same APIs also enable cybercriminals to compromise an entire software supply chain, Sotnikov added.

    At a time when more organizations are deploying APIs, thanks to the rise of microservices, it’s apparent there is a greater need for a tool that dynamically scans APIs for vulnerabilities before they are deployed, said Sotnikov.

    In general, Sotnikov said IT organizations are becoming more sophisticated in their approach to securing software. Ford Motor Co., for example, is using the 42Crunch API Security Platform to secure both internal and external APIs, Sotnikov said. 42Crunch claims its revenues increased 900% in 2020, with more than 150,000 users of the platform.

    As organizations of all sizes become more dependent on software, cybersecurity teams are now reviewing how that software is constructed. Of course, responsibility of security is still shifting left as part of the overall transition to DevSecOps best processes, but Sotnikov said cybersecurity teams still want to verify for themselves that whatever software is deployed is secure. IT organizations are moving away from a “whack-a-mole” approach to security as they embrace DevSecOps, Sotnikov added.

    Unfortunately, APIs don’t always receive the level of attention they deserve. Many developers still tend to view them as an afterthought, and once deployed, it’s not uncommon for APIs to languish for years without being reviewed or updated. Making sure APIs are secure requires dynamic scanning processes to be baked into DevOps workflows if organizations want to ensure the integrity of their software, said Sotnikov.

    APIs are, of course, everywhere now. The days when a handful of APIs were exposed to share data with a limited number of customers and partners are long over. There are almost no applications built and deployed today that doesn’t expose myriad APIs. Cybersecurity teams obviously can’t keep pace with the rate of change being made to those APIs, as new ones are added and others updated or replaced. The onus for securing all those APIs is, now more than ever, clearly on the DevOps team.

  • Solvo Automatically Crafts Cloud Security Policies

    Solvo Automatically Crafts Cloud Security Policies

    Solvo today announced general availability of a namesake tool that automatically creates a least-privilege policy and applies it to application workloads deployed in the cloud.

    Previously available only as a private beta, Solvo will also continually analyze a workload after it’s been deployed to enable IT teams to adjust security policies as additional updates to an application are made.

    In addition, Solvo is making available for free the Solvo Security Genie, which IT teams can use to identify misconfigurations, excessive permissions, privilege levels and third parties that may have access to accounts on the Amazon Web Services (AWS) public cloud.

    Shira Shamban, Solvo CEO, said the primary reason there are so many cloud security issues today is because developers – that lack cybersecurity expertise – are being asked to define policies. Solvo removes that burden by analyzing a workload and creating a cybersecurity policy before applications are deployed in the cloud. That cybersecurity policy can then be automatically applied by the developer.

    Shamban said that approach will reduce a lot of the DevSecOps tension that organizations are currently experiencing as they try to shift responsibility for cybersecurity further left toward developers. While no developer deliberately sets out to deploy an insecure application, shifting responsibility for cybersecurity to a developer who doesn’t really understand what’s required creates a lot of additional stress.

    The Solvo platform, available as a paid subscription or under a freemium model for individual developers and teams, addresses a lot of the cloud security issues that inevitably arise when infrastructure is provisioned as code by developers. It eliminates that stress by automating the creation and application of cybersecurity policies within the context of a DevOps workflows, said Shamban.

    However, a cybersecurity team can also manually edit those cybersecurity policies after an application is deployed, Shamban added.

    As DevSecOps best practices continues to evolve, it is clear the relationship between developers and cybersecurity teams needs to evolve, as well. For a long time, many cybersecurity teams viewed developers as the primary source of the problems they encountered. Getting used to the idea that those same developers are now going to solve those issues on their own requires a level of trust that will take time to build.

    Developers, for their part, are generally accepting of the idea that they should take more responsibility for security, so long as the tools provided to them are not selected by cybersecurity professionals that don’t appreciate application development workflows.

    In time, there is no doubt the cultural divide that exists between developers and cybersecurity teams will narrow. However, it’s arguable that more progress will be made, more quickly, if developers are allowed to choose their own security tools rather than accept an edict from on high mandating a specific approach. In fact, the best course of action for many IT teams is simply to offer words of encouragement to developers that elect to set an example for the rest of their colleagues.

  • How to Mitigate Low-Code Security Risks

    How to Mitigate Low-Code Security Risks

    Gartner predicts that by the end of 2025, over 65% of development projects will use low-code builders. The field of low-code continues to expand. But what security implications does low-code introduce?

    Low-code refers to tools that enable application construction using visual programming models. Adopting drag-and-drop components instead of traditional code, no-code and low-code platforms enables non-technical folks to construct their own workflows without as much help from IT. Yet, handing power to citizen developers with less security training can be risky. Plus, low-code platforms may hold compromised propriety libraries or leverage APIs that may unknowingly expose sensitive data to the outside world. There’s also the possibility that low-code could increase shadow IT if not governed well.

    Low-code opens the door to more producers. But, does it open the backdoor, too? I recently met with Chris Wysopal, CTO and cofounder of Veracode, to discuss the growing security risk posed by low-code applications. According to Chris, hardening low-code environments involves a combination of compartmentalization, dynamic and runtime techniques, and adopting the “least privilege as possible” rule across the board. Below, we’ll expand on potential low-code risks and see what other methods Wysopal recommends organizations employ to secure the emerging low-code paradigm.

    Low-Code Security Concerns

    Verizon’s 2020 Data Breach Investigations Report (DBIR) found 43% of all breaches are connected to a vulnerability at the application layer. Thus, securing these applications, or in the case of low-code, the layer that generates them, is essential for business to function smoothly.

    When it comes to low-code, Wysopal notices a few key risk areas:

    Proprietary libraries with hidden vulnerabilities. By their nature, low-code platforms typically use a good deal of proprietary software, making securing them a bit opaque. These systems could involve a proprietary language, proprietary libraries and proprietary frameworks. If you trust a low-code platform, you place a lot of faith in the low-code vendor to have a strong security process in place.

    Some platforms do generate traditional code, which organizations can export to run on a Node.JS or Java server. Yet, this often involves a mix of code and proprietary libraries, says Wysopal. While you could run traditional static analysis on the generated code, you may miss some context.

    Lack of citizen developer security training. Citizen developers have little technical knowledge, let alone DevSecOps training. If runtime applications present vulnerabilities, expecting no-code users to mitigate them is unrealistic.

    API integrations. If low-code platforms expose an API or generate a web application via an API, the platform could be exposing sensitive data.

    Ways to Harden Low-Code Environments

    To respond to these areas, Wysopal offers some advice for securing low-code environments:

    • Perform static code analysis: Perform your own static analysis on any generated code and test for common errors. “Look at the code, and understand where it interacts with the outside,” Wysopal recommended.
    • Audit proprietary libraries: Whenever possible, Wysopal said he recommends pushing back on the vendor to question them on their application security standards and examine proprietary libraries for potential risks.
    • Verify partners: Similarly, take precautions when working with third-party partners around low-code tools. Partner tools should be carefully vetted and hold some sort of application security certification from the low-code platform.
    • Secure the API layer: Understand what APIs the application interacts with. These connections should be tested dynamically and automatically with an API scanner. Along your journey, consider these API security testing best practices.
    • Compartmentalize: Wysopal also recommends traditional isolation techniques. Consider more than just the application layer; Wysopal recommended isolating the app and running it in a virtual machine or a container.
    • Security training for citizen developers: Since citizen developers are typically not trained on appsec practices, hold security exercises to train them on fundamentals. A helpful demonstration could involve directly attacking an app to find flaws.
    • Apply the least-privilege-as-possible rule: When assigning user capabilities, whenever possible, use secure-by-default settings and allow access only to those that need it.

    By applying dynamic and runtime techniques, you may catch vulnerabilities, such as a cross-site scripting error. However, if you’re working with proprietary low-code systems, you may not be able to fix it immediately! You may have to send a request to the vendor and wait for the bug to be patched. Thankfully, most technology providers take more immediate action in response to bugs than to feature requests, Wysopal noted.

    Change the Attitude Toward Security

    On the low-code spectrum, there is the attitude that “people aren’t really doing mission-critical applications — they’re mainly doing prototyping, or back office automations,” Wysopal said. Or, since low-code applications often do not publicly expose an application, they are deemed low-risk and fall to the bottom of the security team’s inbox and list of to-dos. “We’re still in a world where people don’t secure all applications,” he said.

    However, these attitudes are a bit short-sighted, since “applications aren’t islands,” Wysopal said. Even if applications are intended for internal use only, phishing attempts could expose credentials and gain access to the network. Here, attackers could leverage sensitive resources or steal infrastructure for compute power.

    Thus, all low-code users should be aware of potential threats and change habits to address these risks accordingly. However, the onus is also on low-code vendors to sufficiently arm their systems. Having a vulnerability disclosure, bounty program and an easy means to accept bug reports from white hat security researchers will be necessary to continually patch issues.

    No-Code ≠ No-Bug

    Low-code continues to permeate more and more digital operations, opening up novel potential for citizen developers. While the low-code movement promises impressive returns, it also brings potential risk.

    To mitigate these concerns, we must level up our security understanding and evolve our approaches, Wysopal said. “Any application can have flaws and security bugs in them.” Just because you’re not writing a function in C and are relying on a visual programming model doesn’t mean you’re not introducing flaws.

    Disseminating the real risk of resources and dependencies, along with helpful consumer-facing documentation, will set the superior low-code platforms apart from the rest. Otherwise, putting faith in proprietary libraries will be a tough pill to swallow.

  • Without These 3 Things, You Don’t Have DevSecOps

    Without These 3 Things, You Don’t Have DevSecOps

    DevSecOps adds security to the DevOps software development and releasing paradigm. Everyone thinks this is a great idea, except actual Dev and Ops practitioners, for whom security can be a thankless, stressful time sink. Without the right approach and tools, an organization can run a DevSecOps process that actually contributes little to security. Security simply tags along after development and operations, ignored at every turn. The result is rapidly released, insecure code.

    Industry vendors will tell you they have a DevSecOps solution. You, in turn, may believe you have DevSecOps up and running. However, there can be a big difference between acquiring a DevSecOps solution and fielding a viable, effective DevSecOps program.

    What DevSecOps Isn’t

    1. Every task is manual, and done mostly by consultants.
    2. You send out myriad PDFs or spreadsheets and waste time in meetings.
    3. Your solution or program escalates a lot of security alerts, but never delivers a fix.

    DevSecOps, a Brief Overview

    DevOps, the merging of previously separate software development (Dev) and IT operations (Ops) workflows, has been a boon to businesses. When developers work directly with Ops, which releases and manages the code in production, the entire development-to-release cycle speeds up. This is great news, except when it comes to security.

    Rushing new code into continuous integration/continuous deployment (CI/CD) platforms invites risk exposure. DevOps can easily, but inadvertently, put vulnerable code straight into production on a daily basis. To mitigate this risk, the DevSecOps approach inserts a security function into the workflow.

    This is good, in theory. However, if this is all you have, you do not have a DevSecOps program; you have missed the bigger picture. Without automation, tool integration and results validation, simply injecting security processes into the DevOps workflow might actually make everything worse. Your code will be less secure. The security team will not move quickly enough for the DevOps team, which aims to rapidly release code, and will not always address the security issues raised.

    DevSecOps Requires True Automation

    DevSecOps has to include true automation in the security process. The practice of security pros copying code for security testing and then returning with a spreadsheet of remediation requests simply does not work. Good intentions aside, the Dev team does not want to deal with a long list of security problems, many of which are perceived to be low-risk or could generate false positives. Security is perceived as slowing everything down. There can even be organizational issues that keep the two groups in opposition to one another.

    Instead, code vulnerability assessments should be automated within the DevOps workflow. As code gets checked into Github and then compiled via the build pipeline CI tools, it needs to undergo automatic static, dynamic and interactive analysis. It should undergo a full stack assessment, too. The automated assessment must examine code for vulnerabilities at the mobile or web client layer, the API data transport application network layer and the back end cloud building block app services layer. Automated security testing can analyze microservices, serverless architectures, storage and databases. With this approach, the “sec” part of DevSecOps comprises a “build, set and forget” function. There will be security people involved, of course, but the majority of work is automated.

    This automated vulnerability assessment must then generate alerts and establish a priority hierarchy for their handling. Again, automation plays a pivotal role here, and needs to automatically, and in a meaningful way, triage the long list of findings based on issue severity, privacy concerns and app store blockers. If the assessment produces an overly long list of risks to fix, the DevOps teams commonly tune them out as noise that delays release schedules. However, if the automated process identifies the five or ten “must address” problems, developers are more likely to respond to a realistic, practical set of tasks that create an effective process and resolve issues at the roots.

    DevSecOps Must Integrate With Development and Security Tools

    Security processes are most effective if they integrate with the toolsets used by the DevOps team. These include development tools, cloud platforms and monitoring tools such as security incident and event management (SIEM) systems, as well as ticketing and remediation solutions. That way, security connects directly into the DevOps pipeline; it is neither a digression nor a bottleneck.

    For example, if issues get distributed via ticketing systems, they go directly into developer workflows. Developers might be accustomed to working on issues described in JIRA tickets, for example. If the alerts are suitably prioritized, the developers will likely not perceive the ticket as an imposition on their other work. As security issues appear in JIRA tickets, developers can work on them at a familiar, practical cadence. This improves security and DevOps team collaboration by providing details about issues, occurrences, recommendations and remediation. The results can help remediation of security vulnerabilities be more effective.

    DevSecOps Provides Validation of Results

    A viable DevSecOps program will also provide stakeholders with data about how the program is performing. Reporting and data visualization that documents the results of its vulnerability assessments, and the subsequent remediations, are critical to a successful program. While no application is always perfect on any given release, knowing the risks and having a measurable, clear course of action is critical to a solid DevSecOps program. Successful programs will feature reporting on metrics such as critical issues fixed before production, “business blockers” fixed before rejection, legal costs and regulatory fines avoided and security time and costs saved. Without such reporting and validation of results, there can be no actual DevSecOps. It will be DevOps with some ambiguous security activity surrounding it.

    Application security tools are essential to realizing these three tenets of true DevSecOps and an effective appsec program. The preferred tool should be, as these parameters suggest, highly automated and easy to integrate. It also has to have in-depth reporting capabilities. Armed with the right tools, a DevSecOps group can embrace an approach to the work that is fully automated and intuitively part of the DevSecOps workflow.

  • Tackling Audit Compliance as Code

    Tackling Audit Compliance as Code

    Do the words, “It’s audit time!” make your stomach sink? If so, you’re not alone. Assisting with evidence collection for compliance audits around PCI DSS, SOC-2, ISO 27001, NIST and HITRUST is a drain on DevOps teams’ time and resources at companies of all types and sizes – time and resources that could be better spent driving innovation.

    The good news is, vendors have taken notice, and are delivering new tools and platforms that use automation to eliminate repetitive manual tasks and dramatically speed the audit process. This is entirely in line with the DevOps philosophy of tackling various IT tasks and requirements “as code” to remove tedium and improve efficiency and orchestration. In fact, as this movement to improve the compliance process picks up steam, I believe it’s entirely likely the next evolution is the use of open APIs and online communities where engineers can build and share software to automate a wide variety of evidence collection for compliance.

    But before we can get there, let’s understand where we are today and assess new opportunities going forward.

    Audit Support: DevOps’ Favorite Task

    As keepers of cloud environments, DevOps teams typically spend hundreds or thousands of hours each year gathering evidence for compliance audits. This tedious, manual labor takes significant time away from their primary job responsibilities. Large enterprises often have multiple, overlapping audits each year, with little break from the grind of evidence collection. Companies that make heavy use of the public cloud face additional challenges; the increased complexity means that evidence collection is more difficult, and the fast pace of software development and change management in the cloud (compared to more traditional monolithic application updates) makes it difficult for compliance to keep up. This contributes to an overall lack of clarity and confidence in the compliance process at the leadership level.

    Audit Prep as Code

    When I ran a cloud engineering team at a previous job, we realized the vast majority of repetitive, manual labor involved in evidence collection could be automated to save time and free up resources for other business needs. This automation also improved the completeness and accuracy of the evidence gathered, ensured that important areas weren’t overlooked and allowed for more regular assessment to prevent “drifting” out of compliance in the fast-paced cloud world. While automation helps with multiple aspects of compliance audits (such as evidence-to-control mapping and cross-walking evidence across common control frameworks), it’s the automation of evidence collection that primarily impacts DevOps.

    In this scenario, automated collectors crawl your public cloud environments and connected SaaS systems to rapidly gather technical evidence such as specifics on user access, encryption of data at rest, key management, network segmentation, firewalls, vulnerability scan reports and more. The results are transformed into formatted reports ready for internal review, analysis and auditor review/approval. This, alone, can save thousands of hours annually for typical enterprises facing multiple audits. Even better, the data is considered more complete and accurate from a compliance perspective, because it includes time stamps and other metadata to ensure capture and processing integrity.

    As mentioned, this is well aligned with the broader “X as code” mantra that underlies many DevOps automation initiatives – and why not? What could possibly be a more repetitive, manual task than capturing, renaming, organizing and describing screenshots?

    The Scripting Curse

    When confronted with evidence collection, an engineer’s first thought is usually, “I can write a script for that!” Scripting is a form of automation, but it has some limits in this scenario. First, scripting and doing the necessary QA shouldn’t be your day job; there are better things to spend time on. Second, given the explosion of cloud infrastructure and SaaS apps, there can be a lot of scripts to create. In fact, it’s arguably a never-ending task. Finally, while you understand your scripts, who’s doing the next audit? If it’s not you, are you going to explain and train someone else on all the work you’ve done? Scripting elements of evidence collection is an improvement over doing it manually, but is still only one piece of the larger puzzle.

    Compliance is a Community, not an Island

    So what’s the best way to automate evidence collection? Multiple vendors are tackling the challenge, from cloud platform providers to established GRC vendors and cloud compliance startups – and new tools have already begun to hit the market over the last few months.

    But as discussed, a primary challenge is that there is a lot of complexity in most cloud environments, and tools that approach the puzzle from only one direction – say, a particular cloud platform – still leave a lot of potentially relevant systems untouched. In fact, when you take all of the variations possible with cloud infrastructure into account, this might, ultimately, be a challenge that is best tackled at the DevOps community level.

    Consider this: adherence to industry standards for data handling, privacy and protection is not a competitive issue. We are all better off if everyone shares a basic commitment to complying with these IT security and compliance standards. Viewed from that perspective, the more we can lower the barriers to achieving this compliance, the broader the adoption will be.

    What I hope to see is a DevOps community that coalesces around automating audit readiness. At the engineering level, this could entail sharing of custom collectors. For platform and SaaS vendors, it means ensuring open APIs that allow capture and extraction of relevant data. And the compliance tool vendors must design their collection engines, evidence libraries and usage policies such that customization and sharing is possible. Similarly, automation tools must not only pull data from standard systems, but support pushing data from custom systems or legacy infrastructure. In my view, this bottoms-up approach is the best way to stop wasting DevOps’ time on audit prep, while still allowing enough autonomy to do what works best for their specific environment.

    In this future, then, perhaps an upcoming compliance audit won’t produce a collective groan from the DevOps team – or at least, generate a quieter one.

  • How to Eliminate Incident Inefficiencies

    How to Eliminate Incident Inefficiencies

    In today’s complex, dynamic IT environments, the proliferation of disparate IT Ops, NOC, DevOps and SRE teams and tools is a given – and usually considered a necessity. This leads to the inevitable truth that when an incident happens, often the biggest challenge is collaborating between these teams to understand what happened and resolve the issue. Inefficiencies suffered during this critical stage can have huge impacts on how much each incident costs the business.

    I recently sat down (virtually) with Sid Roy, VP of client services at Scicom, to get a deeper understanding of how IT leaders can more effectively size up these inefficiencies and eliminate them.

    The Costs of IT Incidents

    When asked what a minute of downtime costs, analysts and vendors may provide different answers – but they are more or less aligned around the same order of magnitude – several thousands of dollars per minute. And with an average of five major incidents a month and an average time of six hours for resolution, this easily amounts to millions of dollars a year.

    The three key drivers of these costs are:

    Staffing and team member costs: This includes full-time employees (FTEs), consultants, and overhead when other teams are pulled in to deal with the incident. For many organizations, this can include offshore incident response teams.

    The direct and indirect costs of an IT incident: This includes your infrastructure or capital expenditures like software licenses for monitoring, log and event management, notification, ticketing, collaboration, etc.

    The business impact of an IT incident: This is one of the most challenging and unpredictable variable costs to calculate or manage, and is often the highest of all three drivers. It includes revenue loss/delay or reduction due to a major incident, and the profit or loss due to brand or goodwill impact. It also includes inefficiencies suffered by other parts of the business when critical services they depend on are degraded or unavailable.

    Fragmented Teams Magnify the Challenge

    The incident volume, complexity and throughput obviously affect the number of people and amount of time needed to deal with them and often drive more indirect costs as needed resources pile up. To save on these millions of dollars of costs, you need to be able to collaborate and lower MTTR. As mentioned above, this becomes a challenge in agile IT environments. To help streamline operations, teams need to start asking and answering several key questions:

    • Do you have an up-to-date map of your critical services?
    • Are they prioritized by business criticality (revenue, number of customers, other supported services in the supply chain)?
    • What are the upstream and downstream dependencies of these applications?
    • Have you identified the major infrastructure and application elements in your environment?
    • Are you aligned with the owners of these systems?
    • Do you have real-time knowledge of changes being done to the infrastructure and applications?
    • Do you have monitoring gaps?
    • Which monitoring tools provide you with the best value?

    Answering these questions involves overcoming fragmentation across teams of people, processes and tools – essentially integrating ITSM and ITOM to enjoy the benefits of contextual full-stack visibility and streamlined processes within the organization.

    The Right Combination for Incident Response

    What is the right combination of people, processes and tools we just discussed? Here are the two main guidelines:

    • Set up a major incident management team – ideally, from your existing staff. This team includes three vital roles:
      • The incident manager/incident response commander. This is a designated role in charge of declaring a major incident and taking ownership of it. Their job is to, essentially, stop the bleeding of revenue and costs.
      • The NOC/monitoring team. This is your front line defense. When things go bump in the night or boom in the day, they’re the ones picking it up with their “eyes on the glass” – 24/7. And, they’re in charge of reporting and creating full situational awareness for the incident command through bidirectional communications.
      • The production support team. This team actually effects the required changes and executes the remediating action.
    • Deploy event correlation and automation tools to enable the incident management team. These tools are key, allowing your team to perform the required actions.
      • First, correlate the alerts created by your monitoring and observability tools into a drastically reduced number of high-level, insight-rich incidents by using machine learning and artificial intelligence (ML/AI). Add context to these incidents by ingesting and understanding topology sources, as well. This creates the necessary full-stack visibility and situational awareness.
      • Then, use ML and AI to determine the root cause of these incidents, including correlating them with data streams from your change tools: CI/CD, orchestration, change management and auditing to identify whether any changes in your environment caused these incidents.
      • Finally, automate as many processes as you can to free your IT Ops team from manual, time-consuming tasks. By integrating with collaboration tools, you can also enable the above-mentioned bidirectional communications.