devopsy.kinsta.cloud

Category: DevSecOps

  • VMware Aims to Advance Application Security

    VMware Aims to Advance Application Security

    Most of the tasks associated with maintaining IT security assume that IT security professionals should discover and neutralize all potential threats to an application. At the VMworld 2017 conference this week, VMware is seeking to turn that notion of IT security on its head by focusing the efforts of IT security professionals on the known good.

    Tom Corn, senior vice president for security products at ware, says instead of chasing all the potential bad things that could adversely impact an application, VMware App Defense employs machine-learning algorithms and data VMware collects from its management console and the host on which the applications are running to determine what elements make up an application workload. Those elements are compared to the manifest that was created when the workload was first deployed and, if they have been altered, VMware App Defense will invoke a preloaded library of incident response routines to enforce policy using VMware network virtualization software. Data collected from the host by VMware App Defense is done by inserting code into the kernel rather than deploying agent software.

    Corn says VMware App Defense uniquely provides DevSecOps teams with access to reliable telemetry into the guest operating system environments running on top of VMware. IBM will feed the telemetry data gathered by VMware App Defense into its portfolio of security analytics software, and eventually that data will be fed into the IBM Watson cognitive computing platform to generate application security recommendations. Other vendors pledging support for VMware App Defense include VMware sister companies RSA and SecureWorks, as well as Carbon Black and Puppet.

    Longer term, Corn says VMware expects to also be able to apply this capability to any production environment attached to a VMware NSX virtual network overlay.

    As potentially compelling as VMware App Defense might be, Corn notes that IT organizations should not attempt to boil the IT security ocean. Rather, they should concentrate on new applications currently under development. Otherwise, managing security policies across hundreds of applications made up on thousands of microservices and communicating over microsegmented network overlays might be too complex to manage.

    VMware has been making a case for some time now to employ NSX to take advantage of microsegmentation to limit the flow of east-west traffic in a data center. The idea is that if one node gets compromised by malware, it can only share that malware with nodes participating on the same microsegment of virtual network. VMware is now expanding on that idea in a way that also provides more visibility all the way up the application stack.

    Priced at $500 per CPU per year, VMware App Defense will induce more IT security professionals to recommend deploying its stack over any other available option, VMware hopes. The degree to which IT operations teams and cybersecurity professionals can influence developers in that direction remains to be seen. But VMware App Defense does fulfill its promise, it’s more than likely developers will appreciate the not having to spend as much time defending existing applications instead of writing new ones.

    — Mike Vizard

  • CloudCoreo: Get Your Cloud Security on at Jenkins World

    CloudCoreo: Get Your Cloud Security on at Jenkins World

    I mentioned in a previous blog post that I’d take some more of the people pinging me about Jenkins World 2017 and post about them. One of the companies I’ve picked to highlight is CloudCoreo, makers of AWS security controls and auditing.

    Disclosure: My company, Ingrained Technology, has a business relationship with CloudCoreo outside of our relationship with devopsy.kinsta.cloud. That’s how I know about their attendance. But they’re a cool company for cloud security automation, so I chose to include them in my Jenkins World previews.

    CloudCoreo is based on the premise: What if you could automate and audit security settings in AWS without learning security for each of their services? I’ve used their tools, and I’ll be honest, my personal AWS account had a bunch of security violations. Since I use AWS off and on in spurts, this makes perfect sense, and I was able to clean house a bit based upon the tools’ feedback.

    CloudCoreo’s presence at Jenkins’ World will be to talk about itsr system, but will also concern its new Jenkins’ plugin. While there are tools that allow you to partially automate security generation in AWS, the cool part of the plugin is that it allows your automated system to audit the actual results of a deployment to check against standard security patterns. And those checks include things that are normally outside the build/deploy process, such as user rights and password change frequency.

    One of the directions that cloud is going is putting security configuration directly into templates. But not every template will be designed with the same level of configuration/security. By auditing the results as part of a deploy, weaknesses in templates obtained from external sources easily can be detected early in the development process. This is fully in line with the “shift left” approach currently being used in DevOps, and gives security an edge in automating one more thing. If it is just part of the deployment to kick off this Jenkins plug-in as one of the final steps of deployment, then security can shift from “pawing through tons of config code” to “reviewing results.”

    Right now, security is one of a few items (NetOps being the other) that is on the critical path for DevOps to be both responsive and controlled. Companies such as CloudCoreo are helping make certain that not only does it go out quickly, but it goes out secure.

    I haven’t tried its Jenkins plug-in yet, and don’t currently have any complex AWS projects going on, but the thought intrigues me. Someone should go stop by (the company will be giving a demo of stopping a release for violations at table T1) and see it in action, then report back what you learn. Having used CloudCoreo’s web interface, I expect the results of the Jenkins plugin will be both thorough and definitive, but verification of those suspicions would be nice.

    — Don Macvittie

  • Government Legislation Aims to Secure IoT

    Government Legislation Aims to Secure IoT

    The U.S. Senate is making moves to protect consumer interests, data, and privacy with regard to the internet of things (IoT). Sens. Mark R. Warner (D-VA) and Cory Gardner (R-CO), co-chairs of the Senate Cybersecurity Caucus, along with Sens. Ron Wyden (D-WA) and Steve Daines (R-MT), recently introduced bipartisan legislation called the Internet of Things Cybersecurity Improvement Act of 2017.

     

    Addressing IoT Market Failures

    According to a fact sheet released by the senators, “While ‘Internet of Things’ (IoT) devices and the data they transmit present enormous benefits to consumers, the relative insecurity of many devices presents enormous challenges. This legislation is aimed at addressing the market failure by establishing minimum security requirements for federal procurements of connected devices.”

    The proposed legislation drives home a new reality for IoT device manufacturers: While development organizations currently decide to invest in cybersecurity using a cost-benefit assessment, they are ultimately liable for the security of their data and systems.

    The U.S. Senate’s Proposal

    The proposed legislation requires vendor commitments:

    • To ensure devices don’t contain known security vulnerabilities when shipped.
    • To ensure proper disclosure of new security vulnerabilities discovered within their devices.
    • To prepare remediation plans for any IoT device where known vulnerabilities have been discovered.

    The Internet of Things Cybersecurity Improvement Act of 2017 is tied directly to federal government procurement of such devices but Sonatype predicts they likely will extend into private-sector guidelines moving forward. While the legislation is clearly aimed at consumer protections and privacy, it also focuses on quality, safety and regulatory standards applied to every other major manufacturing industry (“Thou shall not ship products with known defects“). It’s commonsensical in other manufacturing industries, and now Congress is directing development organizations to apply similar quality standards for the software it develops and ships.

    Certify IoT Devices are Free from Known Security Vulnerabilities

    The legislation specifically calls for vendors selling IoT devices “to provide written certification that the device does not contain, at the time of submitting the proposal, any hardware, software, or firmware component with any known security vulnerabilities or defects.”

    Notification When New IoT Vulnerabilities are Discovered

    Following the purchase of any IoT devices, the government wants the seller “providing the Internet-connected device software or firmware component to notify the purchasing agency of any known security vulnerabilities or defects subsequently disclosed to the vendor by a security researcher or of which the vendor otherwise becomes aware for the duration of the contract.”

    Ensure Remediation Paths are Available

    Protections go even further in the post-sale period, calling for clear remediation paths. The proposed legislation would require “any future security vulnerability or defect in any part of the software or firmware [of the IoT device] to be patched in order to fix or re-move a vulnerability or defect in the software or firmware component in a properly authenticated and secure manner.”

    20 Vulnerabilities Per Application

    Recently, Sonatype released its “2017 State of the Software Supply Chain” report that shares empirical evidence of the number of known software vulnerabilities that ship in applications—IoT or otherwise. The report found that development organizations building software with unmanaged software supply chains release applications with an average of 20 known security vulnerabilities, six of which had a Common Vulnerability Scoring System (CVSS) rating between 7 and 10.

    Sonatype’s report also reveals how national governments, federal agencies and industry associations are taking action to help organizations improve open-source hygiene and application security practices. In the past year, new guidelines have been introduced from the White House, Federal Trade Commission, Department of Homeland Security, Department of Health and Human Services and the Department of Commerce to improve the quality, safety and security of software supply chains, related to IoT devices and any other application development efforts.

    The Tide Has Turned

    While the proposed legislation is still open for debate, there is clear evidence that those once ignorant or turning a blind eye to such cybersecurity issues are now paying attention—and they are preparing to make significant changes.

    The full text of the proposed legislation for the Internet of Things Cybersecurity Improvement Act of 2017 can be found here.

    — Derek E. Weeks

  • Synopsys: IoT, ICS More Vulnerable to Security Exploits

    Synopsys: IoT, ICS More Vulnerable to Security Exploits

    A new report shows that internet of things (IoT) implementations and industrial control systems (ICS) are more vulnerable than most to potential zero-day exploits of the open-source protocols, common file formats and APIs they rely on. The report, prepared by vulnerability test firm, Synopsys Inc., is based on 4.8 billion fuzz tests conducted on the company’s customers throughout 2016. The report focuses on six key vertical areas: automotive, financial services, government, health care, ICS and IoT.

    To rank the vulnerability of different protocols, Synopsys measured the time it takes between the start of fuzz testing and when a protocol crash is recorded along with how many crashes occurred over longer periods of time. Newer, less mature or proprietary protocols proved to be the most vulnerable. In some cases, time to failure was measured in minutes or even seconds. Fuzz testing is a method of testing code for flaws and security vulnerabilities that involves throwing large amounts of malformed, random data at the system being tested.

    Industrial control systems are the most vulnerable of the six areas covered by the report. To a great degree that’s driven by the fact that ICS uses a lot of proprietary or ICS-specific protocols, some of which may not have been tested thoroughly enough. Three of the most vulnerable protocols are IEC-61850 MMS, IEC-104 SERVER and MODBUS PLC. The ICS protocol IEC-61850 MMS failed in just 6.6 seconds.

    IoT is the next most vulnerable system. It mixes older, better-tested core IP protocols with newer niche categories such as wireless and ICS. The three most vulnerable protocols for IoT are CoAP Server (failed in 8.5 seconds), CIP and OPC UA.

    It’s important for enterprises to prioritize security in their zeal to build IoT solutions. In some cases, Synopsys revealed that security vulnerabilities stemmed from an incomplete or improper implementation of protocols or unpatched code.

    “The applicability of IoT across all vertical markets and within enterprises of all shapes and sizes has brought us to an important inflection point,” said Brad Shimmin, service director for IT Technology and Software at GlobalData. “Thanks to ubiquitous and readily accessible APIs, development frameworks and even pre-built but extensible apps, virtually anyone can stand up an IoT deployment with very little experience in the way of application development practices. This will undoubtedly reveal the many dangers inherent in building highly distributed systems—dangers affecting both data and logic.”

    Some interesting data from the report: The overall average time to first failure of a protocol was 1.4 hours. When the time to first failure is measured in seconds instead of hours, it indicates a higher potential for criminal exploitation. The most vulnerable protocol tested was the previously mentioned IEC-61850 MMS; the least exploitable was the TLS client, which had an average time to first failure of 9 hours.

    Of the vertical areas the report classifies, the two least risky sets of protocols are the ones used by government and financial services. Synopsys attributes this to the more mature aspects of the categories of protocols used by these industries. They had fewer overall failures and longer test times to their first failure. It would take black hats a lot longer to fuzz them into vulnerability.

    — Scot Finnie

  • SecOps: The Next Stride for DevOps

    SecOps: The Next Stride for DevOps

    Global IT spending is now touching a figure of $4 trillion. In today’s technology-intensive environment, data is the biggest commodity, more valuable and powerful than ever. And like Peter Parker’s uncle Ben noted, “With great power comes great responsibility.”

    Security has always been a big concern for valuable things and IT is no exception. IT as a whole is trying to push security left in the development cycle—trying to involve it in every step of the development cycle. And just when development and operations teams are getting used to the “esprit de corps” we call DevOps, I think it’s time we add the third musketeer: security.

    What is SecOps?

    SecOps is a collaboration between security and operations teams, just like development and operations teams collaborate on DevOps front. SecOps is a set of practices organizations need to follow, processes they need to execute and tools they need to use to ensure the security of their application environment. SecOps is making sure organizations do not sacrifice security to attain set performance and uptime indexes.

    In a typical development cycle—requirements gathering, design, development, testing, implementation or deployment and maintenance—security normally is introduced in the later stages, somewhere between testing and deployment or even later. But SecOps is all about making sure to introduce aspects around security much earlier or at each stage of the software development life cycle (SDLC).

    I know what you are thinking: This is going to complicate things and increase the time to delivery. This is where operations and development teams need to join forces to uncomplicate the things and make it time efficient practice. Next thing you must be thinking of is, Why so much hassle? Think of it the other way. Wouldn’t it save more time when you address the security concerns at much earlier stages than at the time of delivery or implementation? All it takes is an amalgamation of the security group, development team and operations team; a little bit of planning; and a whole lot of execution.

    SecOps + Containers

    Containerization is slowly but steadily moving from an alternative to full virtualization to a serious platform for running your applications. Containers have some obvious advantages including scalability and flexibility, and this solves most of the problems related to resources in case of application development. Reduced size; reduced time to provision application environment and testing; platforms including Docker, Solaris Zones, BSD Jails; and orchestration platforms including Kubernetes, CoreOS Fleet, Amazon ECS and OpenShift make containers a more preferred option for application development environments.

    This increased traction toward containerization points to the increased need to concentrate on security aspects. Here are some best SecOps practices for container environment you and your organizational teams can follow:

    • Authentic sources and images: Always check for authenticity of container images. There are various tools such as Docker’s security scan. With Docker Cloud and Docker Hub you can scan images to check for potential security vulnerabilities. Most images are built from some base image and not built from scratch, so there is always a threat with the used images.
    • Vulnerability management tool: There are tools available in the market to analyze container image formats and libraries for threats before you actually start using them.
    • Follow benchmarks and hardening guidelines: Always make sure you do the checks and follow hardening guidelines for containers, images, hosts and platforms before you start with production. There are few standards and benchmark checks for containers such as CIS’s Docker security benchmark, PCI compliance checklist, etc.
    • Periodic auditing: Regular auditing of your application environment can help you save yourself from the future troubles. Moreover, automation of auditing process can help in detection of unused images and containers.
    • Use of management frameworks: Use frameworks that can automate behavior profiling and control all the users, authorize the access to the containers, images and hosts.
    • Security built in to container engine systems and third-party security solutions: Third-party vendors have a number of applications for container security in addition to security systems of container management platforms.

    Dev + Sec + Ops

    With the continuously increasing business demands for new applications and software, and new practices and development trends such as DevOps, Agile, cloud, automation, CI/CD and others, traditional security needs to upgraded in the new paradigm. Thankfully, some of these practices facilitate the security. Consider CI/CD as an example: Continuous integration requires continuous integration tools, or what we call build servers. Some popular examples are Jenkins, TeamCity, GitLab CI, Travis CI, Bamboo, Go CD, CircleCI and Codeship. The best SecOps practice is to check and fix vulnerabilities at early stages as a part of CI/CD workflow. Integration between authentication, scanning, management tools and CI/CD pipeline tools could be the best possible solution to your security-related problems. Some easy-to-implement solutions can include automated security testing, static code analysis, authentication checks and login tracking.

    SecOps enable organizations in lifecycle management, analysis of security threats, incident management, optimizing and measuring the effectiveness of security controls, reduced breach response time, reduced security risks and increased business security. The basic principle on which SecOps works is Avoid, Analyze, Respond, Review, Repeat. By analyzing the security events and data, you can build incident response plans to avoid future unwanted events.

    Frameworks and Tools

    Now that you have a clear understanding of why you need your security, development and operations teams to work together, let’s see what tools and frameworks you can use.

    • Docker-native tools: If you are using Docker as a platform then you can use few security tools provided by Docker itself for the security of production environment: Docker Bench and Docker Notary. Docker Bench is a script that checks common best practices around deploying Docker containers in production. Docker Notary enables you to check whether content is from a trusted publisher.
    • Chef: Chef provides different tools including Inspec to automate security testing.
    • Puppet: Puppet provides security compliance and policy defining frameworks.
    • Ansible: Ansible provides system tracking, setting up firewall rules, user lockdown and compliance automation solutions.
    • CoreOS Clair: CoreOS Clair is an open-source project for vulnerability analysis in applications and Docker containers.
    • SaltStack: SaltStack can help in orchestration and automation of security practices solutions for containers.

    This is just a look at some of the most popular ones. If you want, there are a number of others that can look after the security of your application environment.

    The main motive behind implying SecOps practices in any organization is involving security team at all possible stages to remove any ambiguity in any stage of development rather than security team providing analysis reports to the operations team and then sitting back and enjoying the show. When these teams perform in a synergistic manner, the business focus can be shifted to other important things.

    About the Author / Chaitanya Jawale

    Chaitanya Jawale is founder and CEO of Opcito Technologies, a leader in microservice-based product engineering and automation. Chaitanya comes with strong background in product engineering, data center automation, DevOps and multi-cloud orchestration and management.

  • Survey: Inviting Security into DevOps Promotes Effective Agility

    Survey: Inviting Security into DevOps Promotes Effective Agility

    Two of the biggest trends in business technology are seemingly at loggerheads with one another. Many companies are under severe pressure to digitally enable their businesses. At the same time, the need for hardened application security has never been more critical than it is now. You can deliver apps quickly and you can deliver apps securely but, generally speaking, the two things don’t happen at the same pace. The DevOps mission is aligned more with development efficiency and agility, but it’s also in keeping with the thinking behind DevSecOps. How are enterprises handling the conundrum?

    According to a new survey from identity and encryption enterprise vendor DigiCert, they are handling it quite well. The recently released “Inviting Security into DevOps” survey found that 98 percent of respondents said their companies are integrating their security teams into their existing DevOps methodologies. The survey found that 49 percent of the respondents are in the process of doing so; the other 49 percent have already done so. Those who report having already integrated security with DevOps are 21 percent more likely to report what might seem counterintuitive: They are doing well at meeting app delivery deadlines.

    “Successful security for DevOps requires a combination of culture building and the right technology,” said DigiCert CSO Jason Sabin. “Companies that can do this and bring in security at the start of a project avoid costly delays, because they deliver their project just once rather than discovering security issues late in the process.”

    The methodology for the survey, which was conducted in May, involved 100 DevOps professionals, 100 IT professionals and 100 security professionals with executive management to management titles skewing 3:1.

    The large enterprises polled for this survey agree it’s worth striving for. Some 88 percent of the respondents called security working directly with DevOps somewhat or extremely important. More than 70 percent of the respondents are concerned that if their companies don’t make this change, one or more of these negative repercussions are likely: increased costs, slower app delivery and increased risks.

    Although nearly all the respondents have integrated or are integrating security within DevOps, they’re not saying it is an easy process. Their top challenges include a lack of a champion for the transition, the security team resists the change, lack of relationship skills required to bring the teams together and it takes much more time than expected—an average of one to two years.

    How should you approach this in your company? First, recognize that it’s no panacea. It’s a logical first step, but don’t spend a year planning it, just do it. Start by appointing or identifying a leader for the project. Someone who understands both sides, ideally, and who knows how to get things done. And install a security lead at the DevOps table for all DevOps business. Integrate, standardize and invest in automating baseline security practices within DevOps workflow. Thinking that way will get you the agility you need.

    Then address what comes next. Have the team identify choke points in the application security process and develop ways to work around them or eliminate them. In other words, attack the problem head on with all your best minds. Don’t forget to look for best practices developed by others. It’s a problem a lot of companies are trying to solve, so networking with people from other companies at industry events may give you your best ideas.

    — Scot Finnie

  • From ‘Water-Scrum-Fall’ to DevSecOps

    From ‘Water-Scrum-Fall’ to DevSecOps

    As organizations abandon the waterfall method of software development for Agile, many are stuck in what Hasan Yasar terms Water-Scrum-Fall. That is, the organization has not effectively embraced Agile and DevOps principles and remains in silos with no links to business goals. Enter DevOps, an extension of Agile thinking. While Agile embraces constant change and embeds the customer into the process, DevOps embraces constant testing and delivery and embeds operations into the team to internalize expertise on deployment and maintenance.

    This is how Hasan started his talk, “Multi Security Checkpoints on DevOps Platform,” at the All Day DevOps conference.

    Picture5.png

    In his talk, Hasan lays out a plan to get organizations to DevSecOps. Really, DevOps is a risk mitigation strategy, built on situational awareness, automation, and repetition. But, security is where a lot of DevOps implementations fall down. The goals for each organization should be:

    • Protecting private user data
    • Restricting access to data/systems
    • Protecting company data/intellectual property
    • Standards compliance
    • Safeguarding disposition/transition

    But, how do organizations get there?

    First, integration and communication. Every point of the product development life cycle should be integrated and communicating, including among the tools. Once this is achieved, you can automate many, if not most, of the tasks. The automated steps are the ones that require less human actions/input to the software development process. This allows everyone to focus on innovation and better code and less on tasks that can be automated by autonomous systems. Also, tasks that can be automated are less susceptible to errors.

    Picture6.png

    Of course, it is the team that ultimately designs, develops and delivers the software. Your team consists of development, IT operations, quality assurance and security. Each has its own skill set and focus, and the overlap is Secure DevOps.

    Picture7.png

    The team is in place, processes are automated and development has started. Development in this day and age has evolved tremendously from even just a few years ago. Previously, software was limited to size, function and audience, and the supply chain was practically non-existent. Your team built each component. Now, development has grown beyond the ability of an organization to develop outside of its core competencies. The supply chain now involves many sources for the code. It is more like plug and play, and this creates lots of vulnerabilities.

    Hasan notes the software supply chain risk factors:

    • Supplier capability – Does the supplier follows practices that reduce supply chain risks?
    • Product security – Is the delivered or updated product acceptably secure?
    • Product distribution – Does the method of transmitting the product to the purchaser guard against tampering?
    • Operational product control – Is the product used in a secure manner?

    To reduce your supply chain risk, Hasan recommends:

    • Ensure supplier security commitment;
    • Evaluate a product’s threat resistance;
    • Create a centralized private repository of vetted third-party components for all developers;
    • Establish good product distribution practices; and
    • Minimize variation of components to make things easier.

    Finally, as you transition to DevSecOps, remember that security must be addressed without breaking the rapid delivery, continuous feedback model.

    Picture8.png

    You can watch Hasan’s entire talk online here for more details and other tips.

    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.  Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here.  This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free and online Oct. 24.

    — Derek E. Weeks

  • The Shifting Data Protection Paradigm: Proactive vs. Reactive

    The Shifting Data Protection Paradigm: Proactive vs. Reactive

    The ever-evolving threat landscape over the last few years should have prompted organizations of all sizes to revise their data protection methods. The volume of incoming data is now staggering, and will only continue to increase—and much of that data is sensitive or of great value to cybercriminals. Data may be structured or unstructured, distributed across numerous locations and be encrypted or unencrypted. Thus, many organizations are attempting to protect data without knowing what they have, whether it is valuable or even where the data resides.

    As the era of big data has exploded, so, too, have the number and size of cyberattacks. Hackers have grown increasingly adept, often refining their skills beyond those of many cybersecurity experts. Today’s hacker may be an idealistic “lone wolf,” but he or she is more likely to be an employee of a foreign government or associated with a gang of highly organized criminals. This means that attacks can be carefully planned and executed over many months, probing a target’s vulnerabilities repeatedly until an intrusion is eventually successful.

    Cybersecurity teams often are at a disadvantage when it comes to protecting data. It has become increasingly difficult to find and retain qualified, experienced cybersecurity experts, and this talent gap won’t be narrowing significantly anytime soon. Economic issues have forced many organizations to trim their budgets, which can result in reduced funding for the security operations center (SOC) or reduced staffing levels. However, even major corporations with large cybersecurity budgets and massive teams are finding it difficult to prevent breaches and keep their data secure. The breaches suffered by Home Depot, Sony and other high-profile corporations—as well as breaches at the U.S. Office of Personnel Management and the Pentagon—demonstrate that cybercriminals are winning more than their fair share of the battles.

    It is not that organizations are unaware of the need to protect their data. Virtually all companies have some type of cybersecurity program in place. However, most of them choose to take either a reactive approach to threats or a proactive security stance. But what they truly need is an approach that integrates both methods.

    Reactive vs. Proactive: The Differences

    With a reactive approach, action does not begin until an incident occurs. This does not necessarily mean that a breach has occurred; it simply means that some unusual or threatening activity has triggered an alert. Unfortunately, an organization can receive several thousand alerts in a single day. Many will be “false positives” and others may have been blocked by defenses, but some may represent a successful penetration of the system. Once alerted, the company’s incident response plan is initiated; in the beginning, the goals are to contain the threat and restore service. Forensics, analysis and efforts to prevent a recurrence follow quickly.

    With a proactive approach, organizations try to detect potential threats before an incident occurs. Files from unknown or suspicious sources can be quarantined automatically for investigation. If found to be malicious, the source, signature or other identifying characteristic can be fed automatically back into the system to block any additional attempts at the gate.

    A proactive approach also includes regular, planned hunting exercises to detect threats that may be lurking in the system but not yet detected or perhaps not yet detonated. Although ad hoc hunting can be accomplished to some degree if performed by experienced analysts, the best method is to automate certain steps so the efforts are sustainable and repeatable.

    Why Organizations Need Both Approaches

    It is always better to prevent a breach than recover from one. However, should—or when—an intrusion occurs, every organization needs a mature, workable, detailed plan to react to the incident. All employees need the training and experience to know what they need to do when the incident response plan is activated.

    Despite the need to have a solid plan to react to incidents, blocking potential threats can be more economical, faster and safer. Therefore, organizations need to be both proactive and reactive to provide the best security for their data. The key is to find the proper balance between the two approaches. Finding the right balance requires evaluating the budget, the skills of staff members and other resources that might be available.

    For both proactive and reactive methods, however, automation is essential. Manual processes simply cannot compete with automation when it comes to speed, cost, accuracy and risk mitigation. With the number of attacks growing by the day and hackers becoming increasingly more adept and persistent, automation provides the best way for organizations to stay one step ahead of the attackers.

    About the Author / Rishi Bhargava

    Rishi Bhargava is co-founder and VP of Marketing for Demisto, a cyber security startup with the mission to make security operations “faster, leaner and smarter.” Prior to founding Demisto, he was vice president and general manager of the Software Defined Datacenter Group at Intel Security, and before Intel, he was vice president of product management for Datacenter and Server security products at McAfee, now part of Intel Security. He has more than a dozen patents in the area of computer security. He holds a BS in Computer Science from Indian Institute of Technology, New Delhi, and a Masters in Computer Science from University of Southern California, Los Angeles.

  • Study: Half of Enterprises Have Achieved DevSecOps

    Study: Half of Enterprises Have Achieved DevSecOps

    The inclusion of IT security into DevOps processes, also known as DevSecOps, appears to be occurring at an accelerated rate. A new survey of 300 enterprise IT organizations published this week by DigCert, a provider of identity management and encryption software, finds that almost half (49 percent) of the respondents says they have completed DevSecOps, while another 49 percent say they are already working on it.

    In terms of overall impact, however, only 22 percent say they are doing well in terms of achieving and maintaining higher levels of security.

    In addition, those that have achieved DevSecOps say it took them anywhere from 12 to 14 months to make the transition. Those that have not completed the transition are estimating it will take them seven to 11 months. Based on the experience of the organizations that have completed the transition, there would appear to be a natural tendency to underestimate how much the cultural difference between developers and IT security teams can negatively impact integration objectives.

    Jason Sabin, chief security officer (CSO) for DigiCert, says that while many organizations may have brought IT security professionals into the process, an increase in the overall security of applications being built requires more time and patience, says Sabin.

    DigiCert recommends IT organizations identify an IT security champion within a DevOps process and automate the implementation of IT security controls as much as possible. Those moves can help lower developer cultural resistance to having to spend time on what often are considered mundane programming issues.

    It’s worth noting that most IT security professionals don’t have much in the way of programming skills. They can secure an application using any number of platforms that have a management console. But understanding how to employ APIs to help plug security holes before an application gets deployed is beyond the capabilities of most IT security professionals. IT security professionals can make developers aware of issues, but in general there’s not much they can do to fix the application itself.

    Also, IT security professionals typically don’t understand the amount of coding that might be required to fix an issue, and they are not always able to access the true risk associated with a specific vulnerability. All vulnerabilities tend to be treated as equal threats regardless of number of instances a vulnerability has been exploited.

    The good news is a full 88 percent of respondents saying it is somewhat to extremely important to integrate security into DevOps. Failure to do so will lead to issues such as increased costs (78 percent), slower application delivery (73 percent) and increased security risks (71 percent). Awareness of these issues should eventually lead to the development and deployment of more secure applications.

    The issue, of course, is that not every development team is equally along the DevSecOps maturity code. Because of that issue, it unfortunately may be years before the preponderance of applications running in a production environment are able to defend themselves from even the most rudimentary cybersecurity attacks.

    — Mike Vizard

  • Barracuda Networks Enhances API to Advance DevSecOps

    Barracuda Networks Enhances API to Advance DevSecOps

    Recognizing that DevOps teams deploying applications in the cloud need a more sophisticated approach to security, Barracuda Networks at the Microsoft Inspire 2017 conference unveiled an enhanced REST API for its Web Application Firewall (WAF), in addition to providing integration with the IT automation framework developed by Puppet Labs.

    At the same time, Barracuda Networks revealed that it has integrated all of it firewall offerings with the Microsoft Operations Management Services running on the Microsoft Azure Cloud. Finally, Barracuda Networks announced it is now including a software-defined wide area network (SD-WAN) capability with the Barracuda NextGen Firewall platform.

    Tim Jefferson, vice president of cloud for Barracuda Networks, says the REST API the company is exposing in its WAF enables IT organizations to better manage security within the context of larger DevOps environment. As part of that effort, Jefferson says, Barracuda Networks also plans to integrate its WAF offering with other IT automation frameworks.

    Jefferson says many IT organizations are discovering that public clouds are more secure than on-premises environments because of the level of security and instrumentation that cloud service providers now routinely include. For example, cloud service providers make it easier to track unusual API calls that might indicate an IT security breach or even an attack in progress. Those capabilities, says Jefferson, make it easier for vendors such as Barracuda Networks to provide more visibility into what’s occurring in a public cloud than what’s generally feasible on-premises.

    However, each cloud service provider has its own unique network stack that requires security tools to be optimized for each platform, says Jefferson. Because of that issue, most IT organizations have not had the security wherewithal needed to rise beyond adopting more than one public cloud service in their production environments, he says.

    In general, Jefferson says, developers are not likely to consume security technologies on a public cloud that can’t be invoked via an API. Because of that issue, many IT organizations are discovering that the security platforms they have employed on-premises simply can’t be lifted into the cloud. That issue, he says, creates a level of friction inside the organization that inevitably hampers usage of cloud platforms more than any other challenge an IT organization faces. Cloud applications require a DevSecOps approach that developers will view as a natural extension of existing DevOps processes, says Jefferson.

    To achieve that goal, organizations need to make it easier for developers to secure their applications and invite IT security experts inside their organization to participate in, for example, scrum teams that collaboration build, deploy and manage applications. In fact, Jefferson notes most DevOps teams don’t even want to talk to a vendor’s sales representative; they prefer to be able to download code that they can test and deploy on their own before committing to buying a license.

    It’s still relatively early in terms of appreciating the impact DevSecOps will have on improving IT security. But one thing is clear: IT security vendors that don’t make it simple for developers to invoke the capabilities they provide soon will be left behind.

    — Mike Vizard