devopsy.kinsta.cloud

Category: DevSecOps

  • Continuous Delivery: No Excuses

    Continuous Delivery: No Excuses

    Jez Humble’s (@jezhumble) career has spanned roles through coding, infrastructure, and product development across three continents and organizations of varying sizes. To say he knows a lot about continuous delivery is a total understatement. In 2010, he and Dave Farley literally wrote the book on continuous delivery—and if you have not yet read it, I would suggest you pick up a copy. It’s a fascinating read.

    I’ve heard Jez speak over the years at a number of DevOps conferences, and I was excited when he accepted our invitation to speak at All Day DevOps. At the conference, Jez presented “Continuous Delivery Sounds Great But It Won’t Work Here,” during which he addressed the four reasons he consistently hears from organizations on why continuous delivery won’t work in their organization:

    • We’re regulated
    • We’re not building websites
    • Too much legacy
    • Our people are too stupid

    Jez also outlined the real reasons behind the stated reasons: Their culture sucks and/or their architecture sucks.

    Jez spent his talk addressing each objection.

    We’re Regulated

    Jez noted it took Amazon four years to go from monolithic to service-oriented architecture (2001-2005) but the company did it. Do you think Amazon is the pillar of free enterprise, free of regulation? Not so. Being a publicly traded company, Amazon is heavily regulated; it is subject to Sarbanes-Oxley regulations; it handles personal and corporate financial and proprietary data; and it provides private cloud services to the U.S. government, including highly sensitive data for the Department of Defense.

     

    null

     

    Amazon Web Services’ GovCloud, in fact, provides the cloud platform for cloud.gov, the 18F project Jez worked on to address the authority to operate process within the government.

    The old process had screened every software application before it was allowed on a federal IT system. It stifled innovation because it duplicated efforts multiple times over. There was no cross-agency assumption that if one agency approved a software package, it was okay at another agency. Cloud.gov moved controls from operations into infrastructure as a service. Now, agencies can receive software through cloud.gov to integrate into their applications.

    null

    The bottom line is continuous delivery is excellent for heavily regulated environments because it gives assurance to regulators by removing opportunities for human error.

    We Aren’t Building Websites

    Jez’s favorite example is HP LaserJet firmware. HP had a 400-person team spanning three continents. Obviously, the firmware was critical for new printers, but the team was moving slowly. Only 5 percent of their time was spent on innovation. HP tried hiring, firing, insourcing and outsourcing. With business school tried-and-true solutions exhausted, and knowing it had to eliminate non-value adding work to increase innovation, the company looked to continuous delivery with two business goals in mind: 1) Get firmware off the critical path; 2) Achieve 10X increase in development productivity, measured by percent spent on innovation.

    HP had other goals:

    • Reduce hardware variation
    • Create a single package
    • Implement continuous integration
    • Implement comprehensive test automation
    • Create a simulator

     

    null

    Note: the chart above doesn’t show the 23 percent of time spent managing the automation tests. Time well-spent.

    In the end, between 2008 and 2011:

    • Overall development costs were reduced by ~40 percent
    • Programs under development increased by ~140 percent
    • Development costs per program decreased 78 percent
    • Resources now driving innovation increased by 8X

    Too Much Legacy

    Jez’s example here is Suncorp, one of Australia’s largest insurers (note: Also falls under the “We’re heavily regulated” excuse). Suncorp was burdened with loads of mainframes and legacy systems, but it built a set of test suites with open source tools to move into continuous delivery.

    Our People Are Too Stupid

    Jez looked outside of the software development industry into an old-line manufacturer: automotives. GM’s worst performing plant had been closed down. GM fired every one of the workers from the plant. The workers were notorious for problems ranging from sabotaging cars to drinking to gambling on the job.

    Remarkably, GM’s union leaders convinced Toyota to hire the old GM employees to learn the Toyota processes, and Toyota hired the GM employees to run their new NUMMI plant. Toyota and the old GM employees showed it wasn’t the people that was the problem; it was the leadership, the management system and the use of obstacles. At the GM plant, an employee had a job and a certain amount of time to do it. If it didn’t get done, the assembly line kept running. At the Toyota NUMMI plant, employees were empowered to ask managers for help—without retribution. The car had to be in a good state before proceeded to the next stage of the production line.

    In software development, this is continuous integration. Toyota’s NUMMI is the inspiration for Lean in the United States.

     

    null

    Jez’s take-home point for any organization is that results aren’t achieved when you adopt practices but don’t implement the culture. You need to:

    • Agree and communicate measurable business goals
    • Give teams support and resources to experiment
    • Talk to other teams
    • Achieve quick wins and share learning
    • Keep going

    Jez dives into more details in his talk, which you can watch here. If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free of charge here.

    — Derek E. Weeks

  • DevSecOps: How Security Teams Can Better Support Their Developer Counterparts

    DevSecOps: How Security Teams Can Better Support Their Developer Counterparts

    Much of the conversation around digital transformation revolves around technology. But the new wave of technology this era has ushered in has also made a big impact on the way organizations, and the teams that comprise them, function.

    This impact on corporate culture has paved the way for the widespread adoption of DevOps, which has broken down silos between developer, quality and operations teams and streamlined the software development process. The next step? Integrating the security team to ensure teams are shipping software that’s actually secure.

    Here are a few ways security teams can better support their developer counterparts:

    Understand How Software is Being Made

    Development teams are under increasing pressure to ship software fast and frequently. Security teams should identify ways to help developers keep up with the rapid software development life cycle (SDLC), while making sure security isn’t sacrificed for the sake of efficiency. Understanding the SDLC for your company is key to finding ways to help that make sense. Have discussions with your development leaders and influential developers to find some ways to win. Create a pilot program with a friendly development team and pour all of your effort into making them successful. Nothing breeds success like success.

    Act as Consultants and Partners

    Developers are taking on more responsibility when it comes to the security of the code they write, which has alleviated some of the pressure put on the security team to secure an entire organization. This has changed the way security teams function and given security professionals the opportunity to act as consultants to their peers in other departments.

    Security team members should approach their developer counterparts with an attitude of enablement. Offering security best practices, problem-solving strategy and general advice will help developers become more confident in their ability to secure the software they build.

    Base all of the above on the security problems they actually have. Don’t preach. Use data from your own application scanning to tailor training. Fill a room with pizzas and developers and talk to them over lunch about problems you can help them fix. Make it conversational. Ask them how they would like to be helped.

    Embrace Ongoing Learning

    Developers have a lot to learn from their security counterparts, but developers can teach security professionals a few things, too. Setting up peer-sharing sessions where both groups can learn from each other will foster an environment of collaboration within the enterprise. Security teams can share threats related to code and specific programming languages and help developers think more like hackers. Developers can share insight into the SDLC and best practices for using code components.

    Combined, the security and development teams should also request support from the leadership team in offering additional educational resources and training.

    Breaking down the silos between development, quality, security and operations to create a true DevSecOps culture will take adjusting on all sides, and it all starts with people. Highlighting the benefit of working together (increased security, streamlined processes and ultimately a better product) is the best motivator.

    — Pete Chestna

  • Chef Advances Compliance Automation

    Chef Advances Compliance Automation

    Chef today expanded the reach of its InSpec platform for automating compliance management with an update that adds support for Amazon Web Services (AWS) and Microsoft Azure public clouds, as well as integration with additional third-party tools. In total, InSpec 2.0 adds more than 30 additional capabilities, including support for Docker containers, Microsoft IIS and NGINX web server and PostgreSQL databases software.

    In addition, InSpec results now can be exported as JUnit format for integration into continuous delivery tools such as Jenkins. Compliance profiles can now also be pulled from Chef Automate.

    Plus, InSpec 2.0 runs 90 percent faster than InSpec 1.0 on Windows and 30 percent faster on Linux, according to Chef.

    Julian Dunn, director of product marketing for Chef, said the primary goal of InSpec is to enable DevSecOps teams to address compliance issues before an application gets deployed in a production environment. It’s not feasible for any DevSecOps teams to remember all the compliance requirements that must be applied when any piece of software or hardware should be configured, Dunn said.

    InSpec provides a mechanism to automate compliance management using a set of declarative tools that don’t require anyone on the IT team to possess programming skills. Dunn conceded it’s still early on in terms of incorporating compliance into any DevSecOps initiative, most of which are nascent efforts themselves. But it’s now only a matter of time before compliance shifts left along with security, Dunn noted.

    Security becomes even more pronounced in the age of the cloud because developers are now routinely deploying workloads on top of infrastructure that is not often managed by an internal IT operations teams, Dunn said. In fact, there have been a recent raft of security breaches stemming from the fact that data was left exposed on a public cloud such as AWS.

    There’s always been a fierce debate concerning the degree to which compliance encourages security. Advocates say that without some basic compliance requirement, the level of security inside most organizations would be more abject than it already is. Others contend that compliance requirements only encourage organizations to implement the bare minimum of security required; thereby creating a false sense of security that cybercriminals easily exploit. Regardless of viewpoint, however, compliance requirements are not going away anytime soon. In fact, major security breaches usually are not accompanied by hefty fines that are based on the number of compliance requirements that were ignored.

    Developers don’t always appreciate all the nuances of compliance when under pressure to deploy and update applications faster than ever. Organizations today need to find ways to enforce compliance mandates without slowing down the rate at which applications are developed. That’s simply going to impossible to achieve without increased reliance on automation. Today, unfortunately, most of what passes for compliance processes don’t begin until long after an application is deployed in production, which makes fixing those oversights once discovered a much more expensive proposition than if they were discovered much earlier in the application development life cycle.

    — Mike Vizard

  • Survey: Not Much Compliance Progress in DevOps World

    Survey: Not Much Compliance Progress in DevOps World

    A survey of 1,500 customers conducted by Chef illustrates the lacking state of DevSecOps in the enterprise today, finding that nearly three-quarters of IT organizations still manually assess whether applications comply with various regulations before being deployed to production. Worse yet, half the respondents also manually remediate any issue once it arrives, which takes days or sometimes weeks to accomplish.

    In fact, according to the survey, more than half the respondents (52 percent) have applied automation to fewer than 25 percent of the servers they manage.

    Manual processes conspire to make IT organizations less agile at a time when the pressure from the business to deploy applications and associated updates faster has never been higher.

    Julian Dunn, director of product marketing for Chef, said compliance—much like security—needs to move much further left into the DevOps process as a subset of DevSecOps. After all, most compliance regulations are trying to set a bare minimum standard for IT security.

    The first line of IT security defense is detecting vulnerabilities before they go into a production environment. Whenever a vulnerability gets exploited, most organizations incur the initial injury. But after the cybercriminals have come and gone the regulators show up, demanding explanations. Those explanations usually don’t do much to mitigate the fines and penalties that are assessed, especially in highly regulated industries.

    Chef has been making the case for applying the same constructs it developed to automate configurations to compliance for some time. Most compliance issues typically stem from one setting or another that wasn’t configured properly, noted Dunn.

    The issue is that most compliance officers inside organizations are unaware that many of these issues could be automatically resolved, and DevOps teams are too focused on daily operational issues to make anyone aware of what’s now possible. But now that DevSecOps is becoming more mainstream, many of the individuals involved are starting to realize they are dealing with the same issues time and again, said Dunn.

    Dunn added that, much like IT security professionals, compliance professionals who typically reside in a risk-management function need to be brought into the application development process earlier, but without slowing down the pace of application development. However, given the current level of manual remediation occurring, earlier participation mostly likely will reduce the level of manual work occurring right before the application is supposed to be going into production.

    When it comes to compliance, most IT organizations are their own worst enemy. Compliance requirements typically are spelled out in arcane language in documents that not many read, much less comprehend. Asking developers to make sense of those requirements is not the best use of their time. Besides, few of them would interpret the requirements correctly. An automated approach to compliance is not only going to create a better application, but it also should reduce a lot of unnecessary aggravation for all concerned.

    — Mike Vizard

  • DevOps Brings Value to Security (and Vice Versa)

    DevOps Brings Value to Security (and Vice Versa)

    Many enterprises today are implementing security solutions that can be deployed and maintained more quickly and easily, and at lower cost, using a DevOps methodology.

    Organizations applying DevOps to security are not looking at IT groups separately as the database team and the application team; rather they see everything as the delivery team. It’s also a team that works together that deliver security services for customers.

    Application, database, network and endpoint security have traditionally been segregated, and you can see how that is built into the tools. DevOps is about bringing these pieces together and integrating operations because it’s about implementing security starting at the top of the value chain—the customers. Ultimately, we look at the value we’re delivering for the customers with security and really making sure we are inserting it into the front of the pipeline. Leading DevOps shops integrate security upfront when building the next big product, feature or service for external or internal users.

    Related Content:

    DevSecOps: Putting Database Sec In DevOps

    DevOps Introduces Complexity. Really

    There are several different models of organizational structure used to insert security into the software development life cycle. Most make sure it is an integral part of everything that gets released. But the point is that it needs to be integrated. It needs to be a living part of everything an organization is doing.

    One effective choice is make sure DevOps engineers are focused on the standardization of the network and the application.

    For example, look at locks. Most of the time, developers are keeping all passwords in locks. As a DevOps team, we’re sharing locks. That means that all credentials, even credit card information, can be exposed. Before we release the features, we need to think about security and remove passwords and credit card details.
    [su_pullquote align=”right”]Security needs to be a living part of everything an organization is doing.[/su_pullquote]
    When we look at the network and the database side, we need to disable all ports, and this is important to do before releasing things. Disable all the network ports and bring all the databases into these, and open only relevant ports.

    If you are going to embed security, it’s actually cheaper, more efficient and faster to do it in the DevOps team; otherwise, you have to train engineers in application, database or network teams on security or add an expert into those teams. But, if you add the security expert into the DevOps team, you could involve fewer people or simply additional people who are cross-trained.

    When we talk about cost savings and cost reduction with our clients, we focus on two things. We look at the model that shows how the cost of finding defects goes up as the product is developed. If you can include quality from the beginning, you reduce cost of maintenance and cost of quality—that’s the first thing. The same is absolutely true of security—that’s the second thing.

    When you’ve got an integrated SRE full-stack engineer working hand in hand with the development team, they’re thinking security, operational agility and maintainability of the system from the get-go, and they’re inserting those non-functional requirements and making sure they’re adhered to across the stack.

    This method is not at the exclusion of having the application team run code tools on security on their applications. Rather, it is someone who is looking at all these pieces and making sure they’re being done correctly.

    Ultimately, we’re producing a product that is not only functional, but actually operable in an efficient and effective way. It can’t break every minute, causing us to spend millions just to keep the darn thing alive. It works the same way with security.

    Even if it’s operable, if we get hacked, the company has a massive data breach liability.

    By having skilled engineers on the front line—particularly skilled DevOps engineers on the front line—you’ve got folks who are thinking in that full-stack mode about the security implications of the system’s operation and any issues they may see, making them more able to identify things that are potential threats.

    — Sean Mack

  • GitLab Acquires Gemnasium to Advance DevSecOps

    GitLab Acquires Gemnasium to Advance DevSecOps

    GitlLab, as part of its effort to extend the reach of its DevOps platform into the realm of security, has acquired Gemnasium, a provider of tools to mitigate vulnerabilities in open source code.

    The goal is to incorporate the IT security tools Gemnasium has developed within a single software development lifecycle (SDLC) platform, said GitLab CEO Sid Sijbrandij.

    Because both companies relied on the Ruby on Rails programming language to write their respective applications, integration of the Gemnasium software into the core GitLab platform will be easier, he said.

    Sijbrandij noted a growing number of organizations are looking to extend the reach and scope of their DevOps processes to include security, also known as DevSecOps. The pitfall they face will be trying to integrate disparate DevOps and security management tools. GitLab is moving to integrate both classes of tools within a single SDLC environment that will make it easier for organizations to make the transition to DevSecOps.

    GitLab, Sijbrandij said, already had been moving down that path prior to the acquisition of Gemnasium. Previous releases of the company’s platform have included support for static application security testing (SAST), dynamic application security yesting (DAST) and container scanning. The separate software that Gemnasium developed will no longer be supported after May 15.

    Related Content:

    How Developers Can Take a More Proactive Approach to Security

    CA Technologies Survey Uncovers DevSecOps Challenges

    Longer term, Sijbrandij said GitLab is moving toward being able to host its software on top of the open source Kubernetes container orchestration platform. That approach will make it easier to automate deployment of its software on multiple public clouds and on-premises IT environments using a zero-touch provisioning framework.

    Ultimately, embracing DevSecOps should result in more secure applications. But just as importantly, IT organizations need to be able to adroitly remediate software vulnerabilities whenever required. There’s a direct correlation between how long malware goes undiscovered and the amount of potential damage caused. It’s not uncommon these days for malware to go undetected for months; as such, eliminating as many of the vulnerabilities that cybercriminals routinely exploit must be a much higher priority for developers.

    Achieving that goal, however, is as much about process as it is tooling. Most developers are not security experts. Conversely, IT security experts typically know little about building applications. Developers are under more pressure than ever to roll out applications faster. But that pressure also often leads to them to short-shrift testing processes that otherwise would have uncovered a vulnerability. Organizations that embrace DevSecOps are trying to address security issues earlier in the process because fixing them once an application is in production is expensive. At the same time, however, no one wants to slow down the speed at which applications are being developed. That creates something of a chicken-and-egg dilemma for IT leaders trying to determine degree to which new tooling will foster changes to processes and culture, or whether they need to accomplish the latter before investing in new tooling.

    There’s always been a natural tension between developers and IT security teams. The hope is that by making them all part of the same DevSecOps team, that tension is either eliminated or sharply reduced. That outcome stands a better chance of being achieved when everyone involved is employing a common framework.

    — Mike Vizard

  • DevOps in the Cloud: Security’s Groundhog Day

    DevOps in the Cloud: Security’s Groundhog Day

    Throughout the internet age, enterprise IT has given security a lower priority than qualities such as speed-to-deployment, scalability, availability and usability. We first saw this in the late 1990s and early 2000s, when IT teams rushed applications onto the web. Amid the glee surrounding the potential of fancy new internet architectures, few thought about the possibility that these applications could become portals into the enterprise for criminals. So, the credo among development organizations was “move fast, deploy fast and seize the future.” There was no concept of risk management, beyond considerations such as availability, scalability and usability. This laid fertile soil for what would become the breach epidemic.

    As we progressed through the years, breaches became so common and massive as a result of the “web evolution” and there became a dire need to manage information security risk. Thus, enterprise security was born. As it evolved, these departments worked closely with IT management, development, infrastructure and business teams to create frameworks that aligned business goals, risk, security and agility. Security and risk management became important parts of development processes and business operations.

    Finally, there seemed to be a path forward to a more secure future … until the future changed.

    Related Content:

    How Developers Can Take a More Proactive Approach to Security

    How Blockchain Tech Can Make DevOps Better

    The future became the cloud revolution, and it plunged us back into the same festering pool of security negligence that we saw two decades ago. Indeed, when it comes to deploying applications in the cloud, security professionals likely can relate to Bill Murray’s character in “Groundhog Day.” Only in the real-life case, they repeatedly relive the same scenario regardless of what they do.

    As DevOps Teams Gain Power, Things Become Less Secure

    Since the emergence of cloud computing, enterprises once again have rushed to take advantage of a new deployment paradigm, and they are prioritizing factors such as scalability, availability and cost-containment, leaving security as an afterthought. As DevOps teams lead today’s much-ballyhooed business transformation initiatives, they gain elevated status within companies.

    Perhaps the most critical development has been DevOps teams gaining control over infrastructure, not to mention development and even corporate purse strings. While these teams follow their own best practices, their processes and protocols often don’t align with their organization’s enterprise security model. Additionally, many cloud providers increasingly are working directly with DevOps personnel, circumventing IT, security and business teams. Not only has this eradicated the interdepartmental collaboration that emerged to manage risk following the first generation of internet applications, but traditional IT and IT security processes have been disintermediated.

    The net result is that, even if a company understands the importance of security, no one team or individual is directly responsible for it because those personnel have been disintermediated. This leaves a gaping hole in enterprise cloud strategies, which is due in large part to confusion related to the shared responsibility model in cloud computing. Many organizations incorrectly assume that cloud platform security equates to application security. But, just because a cloud provider is HIPAA-compliant, for example, doesn’t mean an application deployed within that environment is as well.

    We have critical business applications exposed to a brand-new environment—and security is nowhere in sight. Companies are moving forward with cloud migration without fully understanding what their requirements should be or for what the business, IT and security teams are responsible, paving the way for a second iteration of the breach epidemic. Welcome to “Security’s Groundhog Day.” 

    Securing Cloud Migration and DevOps Processes

    We don’t have to make the same mistakes with the cloud that companies made when they first deployed web-enabled applications in-house. We can break the repetitive cycle by making security and risk management a fundamental part of cloud migration and DevOps processes. Here are a few ways to accomplish this:

    • Know your data. Everyone within your organization has a responsibility to understand what types of data are moving to the cloud on a per app basis, as well as exactly what types of controls are required to mitigate enterprise risk associated with that data.
    • Use a matrix of reference architecture to design secure-by-default solutions to meet varying workload requirements. This will help DevOps teams know when to apply more arduous requirements and when lower risk data needs fewer controls.
    • Verify your plans regularly. Agility requires compromises, and the cloud moves quickly. Without continuous monitoring and rigorous testing, you can’t be sure that what you wanted to build actually made it into production.

    Ending ‘Groundhog Day’

    Many companies are forging ahead with DevOps in the cloud without giving security a second thought, and the resulting consequences are giving other organizations pause. In the movie “Groundhog Day,” Bill Murray’s character had to re-examine his life to break the endless time loop. DevOps would be well-served to do the same: to rethink security and make it a focal point in cloud migration and processes. This is how DevOps can avoid repeating the mistakes of the past. Most importantly, there needs to be a change in the DevOps mindset.

    Security should not be the reason organizations are saying “no” to cloud adoption. When engaged as part of the process, it actually becomes the key to unlock the cloud. Making security part of the process is how you avoid “Groundhog Day”!

    — John Turner

  • DevOps Chat: ASRTM for DevOps with Rohit Sethi, Security Compass

    DevOps Chat: ASRTM for DevOps with Rohit Sethi, Security Compass

    In this DevOps/Security Boulevard Chat we speak with Rohit Sethi, COO of Security Compass about ASRTM, which stands for Application Security Requirements and Threat Management. Gartner has recently released a hype cycle on ASRTM, with Security Compass and its SD Elements offering named a leader in the market. Rohit gives us a good background and foundation on ASRTM and why it is important for both DevOps and security teams.

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

    Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 119457″ target=”blank” width=”200″ height=”200″]Rohit Sethi
    Rohit Sethi joined Security Compass as the second full-time employee. As COO, Rohit is responsible for setting and achieving corporate objectives, company alignment and driving strategy to execution. Previous to this role, he managed the SD Elements team. Rohit specializes in building security into software, working with several large companies in different organizations. Rohit has appeared as a security expert on television outlets as such as Bloomberg, CNBC, FoxNews, and several others. He has also spoken at numerous industry conferences s and/or written articles on major websites such as CNN.com, the Huffington Post and InfoQ.[/su_pullquote]

    Alan Shimel: Hey, everyone. This is Alan Shimel for Security Boulevard Security Chat, and this will also be appearing on devopsy.kinsta.cloud under DevOps Chat. So two chats for the price of one, though it’s one chat. Welcome, and we have a great guest lined up for today. I have Rohit Sethi—and I mispronounced that. I think it’s actually Rohit Sethi. But in any event, you can correct me. Rohit, welcome.

    Rohit Sethi: Thank you.

    Related Content:

    How Developers Can Take a More Proactive Approach to Security

    DevOps Chat: Aqua Security Seeks To Secure Containers

     

    Shimel: Just for the record, say your name correctly.

    Sethi: Rohit Sethi.

    Shimel: Rohit? Okay. Rohit, you know, as my mom used to say, “Call me anything you want, but not late for dinner.”

    Sethi: [Laughter]

    Shimel: Welcome to Security Boulevard Security Chat and thanks for joining us. So you are the COO of Security Compass, correct?

    Sethi: Correct.

    Shimel: And there’s probably people in our audience who maybe are not familiar with Security Compass. So why don’t we start there. Can you give us a little bit of background on Security Compass?

    Sethi: Sure. We are a firm that is specializing on software security. And we have three main offerings around that. So we have an advisory practice that does penetration testing, and code reviews, and threat modeling, but also helping people build up their secure software program. And especially more recently building up their dev sec ops program and building security into their DevOps pipeline.

    Shimel: Mm-hmm.

    Sethi: We have a training practice, which is specialized in training developers. We’ve partnered with ISC-Squared and we offer a certificate or batch program on secure development for software developers. And then we have a product called SD Elements, which is an application security requirements and threat management. I know that’s a mouthful. And what we’re going to talk about today is a platform that helps people build security and compliance to some extent into their software development process, and particularly for agile and dev ops processes.

    Shimel: Excellent. Now, so a couple of things that we want to talk about relate. And one of them is recently Gartner’s come out with another magic quadrant or a new magic quadrant where they’re kind of lumping together what I personally always thought of was two distinct areas. And they’re calling it – and I’m going to mess this up. Why don’t you help me? AR –

    Sethi: ASRTM.

    Shimel: ASRTM. Why don’t you tell our audience what that stands for?

    Sethi: Yeah. ASRTM is application security requirements and threat management. And it’s not quite a magic quadrant yet, but it’s on the hype cycle.

    Shimel: Hype cycle. You’re right.

    Sethi: Okay. So they’re identifying it as a sort of an emerging category for people to start paying attention to.

    Shimel: Yep. And so for our audience and for me, talk to me. How did the nexus here between them?

    Sethi: eah. So you can think of [Laughter] anything in this category as being tooling that helps you to build security into the onset of development. Most of the tools that exist in the application security category today are some form of static analysis, dynamic analysis, interactive application, security testing. So really all different kinds of testing looking for security defects, or blocking the tax in real time. Right? So real-time application security protection or web application firewalls.

    And many people their entire budget is on testing and sort of blocking attacks. But really very little focus on building security from the start, except for perhaps in training. So everything in this tool category is essentially some kind of product that will help you to systematically and in kind of a scalable way build security in so that you don’t get those defects when you do your testing. And perhaps more importantly, to prevent defects that perhaps those automated tools are just incapable of finding.

    Shimel: Got it. Got it. Got it. Got it. And so I think we’ve laid the foundation, if you will, Rohit. Let’s jump into a little bit of how this relates to dev ops and what we call dev sec ops. So why –

    Sethi: Yeah.

    Shimel: Go ahead. Why don’t you take a lead on that?

    Sethi: Yeah. For sure. So DevOps is a phenomenon that it’s not just for sort of fast-moving organizations. Even some of the slower or I guess you’d say larger companies are starting to embrace DevOps, as you know. And it’s becoming really quickly sort of a mainstream philosophy. And there’s just really rapid pace of change of tooling that people are looking at – and not just tooling, but processes, to be able to accommodate continuous integration and continuous delivery in all of the mentality changes and processes that have to change to allow that to happen.

    Now, when we think about the traditional secure software development life cycle, there’s a lot of activities that we’ve typically suggested in the security community about following a secure SDLC, that really kind of incongruent with this idea of either having really fast sprints or no sprint, no iterations, just being able to take one ticket at a time, build it, and deploy it. So the idea of doing like an architectural analysis, or a one-week or two-weeks threat model, these things are sort of thrown out the door when the pace of development is too fast to keep up with it.

    And so that kind of opens up the need for automation. Now, there’s sort of a trend, and I would call it, I would label it a dangerous trend, that people are looking to 100 percent automated solutions to sort of take away the security problem. Right? So you’ll see sometimes people will put together presentations on DevSecOps and they’ll say static analysis is sort of your way to handle secure coding. And then perhaps some penetration testing on a periodic basis and you’ve kind of checked off the box for secure development. But the reality is that, in fact, security is a lot more complex than that.

    Static analysis tools and dynamic analysis tools have their strengths, but they also have significant gaps. We actually put together a white paper that talks about the missing parts of what scanners can’t find, false negative gap. And one of the interesting things is if you look at sort of CC plus plus development for a second, one of the most pervasive vulnerabilities is buffer overflows. This is the thing that caused Heartbleed and WannaCry and pet. Yeah. It’s sort of the underlying root cause there was some memory management issue.

    And if you were to take some of the best practice in terms of highly automated scanning solutions and put them all together, they’d still be able to find less than half of all buffer overflow vulnerabilities. Yet, this is what a lot of the industry is converging on as good enough from a software security perspective.

    So not everybody looks at it that way, and there’s a lot of people who realize that there’s a gap here that we need to do more than just scanning. It is an essential part of the solution, but we need to be able to identify what are all of the relevant threats to an application development, and how do we actually build mitigating controls rather than fixing the vulnerability after the fact? So prevention instead of detection.

    And that’s really where the ASRTM category fits in. It allows you to define what those controls are and build them into the software development process. Not only, in fact, from a security perspective, but also like compliance control, some of the GDPR issues that will come up there.

    You have to kind of build data protection by design and default. You need a system, a systematic way to identify these as essentially requirements that go into your backlog, right, and that you can track whether or not they’ve been tested. And that’s quite different than the approach that people have typically taken to finding vulnerabilities after the fact and fixing them.

    Shimel: Mm-hmm. So Rohit, our audience, especially from devopsy.kinsta.cloud, of course, is extremely savvy to the whole DevOps and DevSecOps terminology and kind of what’s happening. One of the issues that we see with this, though, is so many of our security solutions are geared for security professionals.

    Sethi: Yeah.

    Shimel: Where so much of the real responsibility for secure coding and secure apps lies with the developers.

    Sethi: Yes.

    Shimel: Right?

    Sethi: Yeah.

    Shimel: And to that no one – you know what? I’ve never met a developer, Rohit, who raises his hand and says, “I want to develop insecure code.” Or, “I want to have an insecure application.” They all want security, obviously.

    Sethi: Yeah.

    Shimel: But they may not have the expertise. They may not have the support. They may not have the time, frankly, to do it right.

    Sethi: Yeah.

    Shimel: So how does like a Security Compass type of solution help not only the security guy, but the developer, as well?

    Sethi: Yeah. Excellent question. So the way that the work flow in an ASRTM solution works – and I’ll talk specifically to ST Elements, which is our product. But we’re not the only product that does this. Is that somebody in a product team – so we have a lot of clients that use it this way. It’s sort of a self-service model.

    So let’s say like a project manager. And so you mentioned developer, but I would extend that to the entire development team, right? Product owners, product managers, scrum masters, etc., right, who are involved with building software. So you take sort of a lead, whether that’s product manager, project manager, product owner, scrum master, lead developer. And they fill out a questionnaire that’s kind of like a base online ramp up of that software they’re building. So they’ll answer like a multiple-choice questionnaire.

    And then based on the results of that questionnaire, they’ll get a defined set of prescriptive controls that are essentially security user stories, right, that you need to build into your software. And then what they’ll do is they’ll integrate it into gira, or Microsoft Team Foundation server, or whatever it is that the development team is using to manage their backlog. And then the product owner is then responsible for grooming it, just like they do feature or functional stories. Right?

    So now what we’re doing is we’re taking the backlog, which is sort of the de facto list of work that needs to be done, and we’re putting non-functional requirements alongside the functional requirements, which allows the development team to take control of when they’re going to implement security work or security features, as opposed to just reacting to a security defect that’s found later on. So basically you’re turning unplanned work into planned work. So that’s the first thing that you do to sort of empower the development team.

    The other, of course, is that when you take a look at these requirements and these controls, you actually start to bake training into it. So someone might get a control that talks about how to implement a secure password reset. Right? So this is a feature in the system that is the kind of thing that you really can’t find with an automated scanner, but that could lead to significant risk if it’s done incorrectly.

    So you can actually have a Gira ticket that talks about the correct way to implement secure password reset, and you can have an actual embedded training module so somebody could actually learn about well what are the ways that people exploit password reset at the time that they implement the control. So it’s what we call just-in-time training. We think it’s a really important and powerful concept, especially as it relates to fast-moving development.

    Shimel: Absolutely. So Rohit, I’ve always wanted to ask this question, then. And that is it’s incredibly difficult, then, as a Security Compass, let’s say –

    Sethi: Yeah.

    Shimel: To, I mean, number one as a salesperson to, who do I sell to? Who has the budget? Who is my technical stakeholder?

    Sethi: Yeah.

    Shimel: Who is making decisions? But beyond, you know, pity, no one’s going to play hard to the flowers for the sales team. [Laughter] But beyond that, as a solutions provider, serving two masters here.

    Sethi: Yes. Yes.

    Shimel: How?

    Sethi: You know it – go ahead. Sorry.

    Shimel: No, no. I was going to say how does that – I just, it’s gotta be really hard.

    Sethi: It is hard. I wouldn’t say that it’s easy at all. But I think that it’s critical work. Like our vision as a company is a world where you can trust technology. And we really think that if we don’t do security right, that that vision will not be realized. People will be afraid of technology to some extent. We won’t be able to exploit the possibilities that technology affords us because we’re afraid of vulnerable technology.

    And really, when you think about the root cause of most of the security incidents, sometimes it’s an insecure web application, but sometimes it’s a vulnerability in your desktop or operating system, or like a browser component or something. But so often it’s a secure coding issue. And so much of the sort of cybersecurity budget and infrastructure is based on the fact that well, let’s just take for granted that the software is insecure, and let’s find ways to mitigate the risk.

    And of course we’ll never get 100 percent secure code. But we really think that there’s a huge gap between what we can feasibly do, right, versus what’s being done in industry today. And so that motivates us. And I think often when we start to talk about the data, we talk about and when we’re talking to the chief information and security officer, or the chief information officer, we talk about a visibility gap that they have, right?

    Which is that right now the way that most companies work is they have a GRC solutions and sort of a policy departments to talk about what their high-level information security policy is. And then they may have some automated solutions to help enable that policy. But there’s sort of a gap between this high-level policy and then what are the specific things that an IT team needs to do to make sure that that policy is being followed and being able to track that?

    And that’s really, I think, at the heart of what an ASRTM solution provides is the ability to take this policy, turn it into procedure, turn it into something you can track, and ensure consistency, right? Because you can’t rely 100 percent on sort of automated scanners to catch everything. So you need to have this sort of translation there. And we find that that works pretty well. People are receptive to that need.

    And then, in fact, it’s not just application security, but it also involves infrastructure security, hardening servers, and that sort of thing, bender security, bender risk management, cloud security, how secure your cloud applications, and how do you know what to test against? So just like a variety of needs are met by adopting a program, really, that allows you to define your security controls at the granular level that your DevOps teams can implement them and you can track that.

    Shimel: Fair. Fair enough. So what does the future hold here, then?

    Sethi: Well, my hope is that we realize that vision, right? We get to a point – what I would like to see, for me success in the long term is that when we find that there’s a vulnerability that’s exploited in the wild that that vulnerability never creeps into code again. Right? Like if we know how to mitigate it, then it’s mitigated forever. And we’re so far away from that reality right now. Right? Like a lot of the real-world exploits are traced down to what is the root cause? It’s a secure coding issue that we’ve known for 15 or 20 years, in some cases.

    And that’s just not good enough. So we’d like to get to a place where the only hacks that occur are really novel. Right? Like we’ve never seen anything like this before. And some really profound security researcher has found a security issue that they’ve spent a significant amount of time understanding that specific domain. Right? But not sequel injection. Right? Not parameter manipulation. Not things that we’ve known for years. And that’s really, I think, where we want to go. And I think that inevitably that’s the direction that the industry is going to move towards.

    Shimel: Agree. Agree. Rohit, when we started, I told you the time goes quick. And we are coming up on our 15-minute window. But let me give the listeners – we want to find out more about Security Compass. Where can they find out more?

    Sethi: Well, of course, you have, you know, SecurityCompass.com talks quite a bit about what our offerings are. You can feel free to e-mail us, info@SecurityCompass.com. I’m personally on Twitter so you can follow me. Just @RKSETHI. We have a LinkedIn page for Security Compass, as well. So lots of different ways you can interact with us.

    And like I said, we offer training. So a lot of people who are, just want to learn more about application security, we have courses that you can just sort of enroll yourself. And we’ll be releasing more of those in the near-term future, as well.

    Shimel: Got it. All right. So Rohit Sethi, thanks very much for being our guest on this episode of Security Boulevard Security Chat, as well as DevOps Chat. And we look forward to hearing more about Security Compass in the coming months. Thanks for being our guest today.

    Sethi: Thank you for the opportunity. Appreciate it.

    Shimel: All righty. Rohit Sethi, Security Compass here on Security Boulevard. This is Alan Shimel, and we’ll see you soon on another DevOps or Security Boulevard Chat.

    — Alan Shimel

  • How Developers Can Take a More Proactive Approach to Security

    How Developers Can Take a More Proactive Approach to Security

    Developers tend to get thrown under the bus when it comes to application security, but recent data shows that developers do, in fact, care about security. Take mitigation for example. Developers don’t try to rig the system by rejecting findings as false positives or as mitigated by design. Developers documented mitigations for just 14.4 percent of all flaws found by CA Veracode’s platform in the past year.

    Still, IT and development professionals shouldn’t wait for a major breach to occur to uplevel their security skills. Here are a few ways developers can shift their approach from reactive to proactive.

    Seek Out Alternative Education Options

    The education path for IT and development professionals has some serious holes, especially when it comes to security. A whopping 76 percent of IT leaders report that they weren’t required to take a single security course in college. Many technology professionals are entering the workforce without a cybersecurity education, thus requiring them to learn their most crucial skills on the job rather than in the classroom.

    Across industries, online learning has emerged as one of the most valuable resources for working professionals who want to learn new skills. Online education is flexible, personalized and covers a wide array of subjects. The impact is clear: Simply by completing basic online learning courses about common vulnerabilities can help a developer improve their fix rate by an average 19.4 percent.

    Related Content:

    Cloud Services Demand Security Up the DevOps Stack

    CA Technologies Survey Uncovers DevSecOps Challenges

    Many times, developers are forced to take education into their own hands. Sixty-eight percent of IT decision makers report that their organizations don’t provide adequate security training, so they must find a way to fight for educational resources. Teaming up with security colleagues to make the case to the C-suite is one way to do this. A two-pronged approach could make a difference when asking for increased training budgets.

    Be Aware of Open Source and Component Risk

    The industry is facing a dilemma in securing the software supply chain. As development processes become increasingly automated, a lot depends on how well development teams can piece together open source components with their own handwritten code. This practice increases efficiency and lowers technical debt, but opens new doors for hackers.

    Open source components usually carry their own set of vulnerabilities and risks. In the past year, the majority (87.6 percent) of Java applications scanned by CA Veracode suffered from at least one component-based vulnerability. Many organizations either aren’t aware of these vulnerabilities or don’t even know what components make up their software products.

    Beyond lack of awareness, consistency in patching is also a problem. Once a development team integrates open source components into their code, they rarely update when security patches are released. Attackers frequently jump on newly disclosed vulnerabilities to target victims that fail to update fast enough, so thorough patching is crucial.

    Simply put, teams must bring a better discipline to the use of code components. Finding new ways to monitor, track and manage open source components in code is one of the most impactful activities developers can participate in to ensure secure software.

    Leverage Security Teams as Consultants

    As DevOps practices spread and more organizations require developers to do their own security testing, the role of the security team is evolving. Security professionals are becoming more like consultants that can uplevel developers’ skills with advice on best practices, strategic planning and individual coaching. This is where the idea of DevSecOps comes into play.

    To bridge the gap between development and security teams, attitudes need to adjust on both sides. Security teams must begin approaching developers with an attitude of enablement and developers must be willing to team up with colleagues that have a hacker mindset and expertise in understanding threats to the organization.

    Developers who see security experts as a resource rather than an opponent can make significant improvements to the security of their software application portfolios. Developers who paired their vulnerability findings with remediation coaching from security experts saw an 87.6 percent better fix rate than those who received no coaching.

    When it comes down to it, both security and development teams should try to be more proactive. If both sides commit to breaking down silos and learning from each other, they will find that DevSecOps is the best way to ship software both quickly and securely.

    — Pete Chestna

  • Predictions for DevOps Security in 2018

    Predictions for DevOps Security in 2018

    Automation continues to be a major driver of DevOps as a whole. In 2018, we’ll continue to see a shift in how and where automation is applied in the DevOps life cycle. More specifically, DevOps will move toward adoption of integrated automation and security orchestration solutions. The need to move away from a reactive DevOps security model will see more teams integrating new solutions that leverage machine learning, analytics and orchestration that can provide incident management insights in real time. Based on that approach, here are three security predictions for DevOps in 2018.

    Continuous Response Will Become a Fundamental Part of the CI/CD Process in 2018

    DevSecOps will increasingly integrate security into the continuous integration/continuous delivery (CI/CD) process through continuous response using automation that eliminates manual processes. This continuous response as part of the CI/CD chain will go beyond ensuring that an application satisfies certain defined baseline security needs to automated threat hunting that maximizes security team response accuracy. By injecting security monitoring on the code level, continuous response can happen right from development to pre-production to the ongoing use life cycle. When this is done right, responding to security vulnerabilities becomes easier during each step of the process, reducing the time taken to fix or mitigate vulnerabilities.

    DevOps Will Transition from Reactive to Predictive Security Processes

    As market sophistication increases around cloud security, integration and incident lifecycle management, companies will become much more proactive at managing security within the DevOps life cycle. The need for integrating security orchestration into the development process rather than reacting to issues once a project has been deployed to production is clear based on the huge costs of reactive measures. As these platforms and tools become more available in 2018, companies will begin adjusting their DevSecOps mindset on both a cultural as well as products level to create a more holistic, inclusive process.

    We’ll See Solutions that Integrate RASP with Security Orchestration

    Having a comprehensive security solution for web applications with heightened detection, visibility and remediation capabilities will be key to response acceleration of web application vulnerabilities in 2018 and beyond. By extending security orchestration to web application security, developers and security teams will be capable of closing the interoperability gap. The key will be an increased visibility into the application and context of which attacks are happening by protecting web applications and API services in real time.

    Integrated solutions will enable users to design and deploy custom security rulesets based on the rich data derived from analytics to improve RASP solutions through expanded orchestration capabilities. The result will be a much-improved web application security layer capable of identifying and isolating active attackers, separating breaches from attack attempts and creating and enforcing active protection policies for better application protection. This ability to respond to escalating web-based attacks will eliminate days, weeks and months of manual tasks.

    — Rishi Bhargava