devopsy.kinsta.cloud

Tag: security tools

  • DevSecOps Deluge: Choosing the Right Tools

    DevSecOps Deluge: Choosing the Right Tools

    In the last few years, DevSecOps has become the security process of choice for many forward-thinking enterprises. 

    These organizations have come to understand that fixing bugs in the latter stages of product and application development offers no favors to anyone but cybercriminals. So, they have overhauled traditional processes and united development, operations and security teams to form DevSecOps where the teams now work in tandem, cooperating to embed security into the entire process of application and software development.

    The benefits of this are clear; finding and fixing bugs early closes doors on cybercriminals while bringing peace of mind, cost savings and better products to customers. However, one of the challenges many organizations face when transitioning to DevSecOps is making the process seamless, ensuring it doesn’t slow down the software development life cycle, make security checks more cumbersome or cause frustration among teams. 

    Security teams need to ensure their DevSecOps program is delivering value to the culture of the organization while speeding up time-to-fix, capturing the right metrics, and categorizing and prioritizing issues based on their risk so that nothing goes live that could cause major damage.   

    Additionally, they also need to select the correct DevSecOps toolkit to carry out application security testing while ensuring the tools easily integrate into software development and can be used across multiple projects. When identifying tools for testing, DevSecOps teams are often overwhelmed by the huge range and volume available, which makes choosing which ones to use and learning how to use them a minefield, even for those with the right training and know-how. 

    A DevSecOps automation program needs lots of technical tools and cultural aspects to come together to make it work. Security teams need static analysis tools to check the code, third-party library analysis to check the dependencies, separate analysis to check the infrastructure-as-code (IaC) configuration, scanners to check containers for issues, tools to test the running system, cloud security checks and infrastructure testing for patches and ports. They also need to match these tools up to the right technology each team is using and keep up with the constant changes.

    Given all of these complexities, how can DevSecOps teams overcome these challenges and build out an effective DevSecOps program with the correct toolset? 

    Here are some top tips to help them along the way.

    Keep Security Processes Flexible 

    Your teams are going to be using different technology stacks, different languages, frameworks, and so on. If you tie your process too tightly to a few tools, it’ll be harder to slot in new checks when things change. Remember that the aim is a consistent, repeatable security process with the right visibility—the technical tools feed into that, but they are not the whole process. What security checks will you need in 12 months that you don’t have now? What about 36 months? These are questions that must be asked continuously. 

    Automation is Your Friend

    If development pipelines are running smoothly and automatically, then any manual security steps are not going to fit in with the process. Automating security tools together—from orchestrating their running to aggregating their responses and managing issues—will save a lot of time and give you the results you need in line with your releases.

    Keep an Eye On Your ROI

    It’s very common for big-ticket commercial tools to be underused; you have the licenses for repeated testing and you have frequent code drops, but the processes or the integrations mean testing isn’t applied as often as needed or the results take time to collect and process. Explore ways to bring commercial tools easily into the existing processes.

    There’s No Such Thing as a Free Lunch

    The open source community provides great security tools, but remember: There is a cost associated with the time it takes your teams to use them and to manage the outputs. From developers learning how to run them to the time it takes to actually run them or extract the results or manage false positives—these aren’t free. A ‘free’ tool that costs two hours of work every release might not be worth it.

    DevSecOps is All About Collaboration

    Weaving security checks into development processes, CI/CD pipelines, ticketing systems and sprint meetings help security to be part of the development process, but not every developer is—or wants to be—a security expert. Think about how the aims of development and security can meet in the middle. How can developers include security without much effort or thought? How can security help supply the tooling and help triage issues in developer pipelines? How can the process conform to auditors’ tools and with correct profiles, not just turned down to zero to avoid reporting issues? How can security add value at scale to help developers fix issues faster regardless of the tooling being used?

  • How DevSecOps Teams Can Level Up

    How DevSecOps Teams Can Level Up

    In 2019, I wrote a post detailing the traits of DevSecOps—the practice can be defined as the process of security automation in which IT and security are more de-siloed. DevSecOps introduces a more intentional culture wherein security-by-design principles are baked into the software development process early on. All in all, the aim is to have security enable development, not stall IT and slow down the SDLC.

    So, years later, how is DevSecOps doing? Has it achieved this ideal? Well, I recently met with Jeff Williams, CTO and co-founder of Contrast Security, for insights into the state of modern DevSecOps. According to Williams, most large companies still have real problems with application security and software dependency providence is constantly in question. We’ve recently seen this reality rear its ugly head amid exploits in frameworks like Log4j and Spring4Shell.

    Large organizations are likely carrying tens of thousands of vulnerabilities in their backlog. Yet, as consumers, we happily trust software for our critical applications without knowing what lurks behind it. “The industry has a real transparency problem,” said Williams. And as applications are getting more interconnected, they are getting more complicated and they’re getting more critical, Williams added. “These three Cs—connected, complicated and critical—make security harder.” These conditions are culminating in what he called “a perfect storm.”

    6 Ways DevSecOps Teams Should Respond

    So, how should DevSecOps teams respond to the seemingly endless barrage of new vulnerabilities and attacks? Williams shared some general ways teams can increase their security posture.

    1. Practice Security in Sunshine

    It’s easy to point fingers when something goes wrong, especially if it’s a serious vulnerability or attack. Instead, Williams encouraged teams to practice what he calls “security in sunshine.” This is an attitude that gives more transparency to security issues internally. Embracing a culture of blameless retrospectives can ensure employees are comfortable bringing up issues within their team.

    Security in sunshine can be adopted in an external-facing way as well. Williams likened it to how, in product manufacturing, it’s standard practice to share a bill of materials (BOM) with trade partners. We may see similar labeling standards emerge for software in the form of software bills of materials (SBOMs) so that external consumers are better aware of dependencies and potential threats, Williams suggested.

    Cybersecurity awareness certainly takes a communal effort that requires transparent communication. We see this realized daily in bug bounty programs, CVE reports and fixes to open source software. Bringing potential threats into the light of day is necessary to squash vulnerabilities before they are exploited.

    2. Translate High-level Requirements

    Security guidelines issued by bodies such as NIST and ISO are essential to keep in mind. Implementing the concepts these guidelines recommend, such as the principle of least privilege, multifactor authentication and zero-trust architecture, are considered best practices by most security professionals. However, these high-level requirements don’t often translate down to the developer on the ground floor. “The developer needs those requirements translated down four levels to specific technologies they’re working with,” said Williams.

    A programmer needs more realistic advice on how these guidelines affect, say, Spring Boot applications or how they should configure permissions in AWS. According to Williams, teams must interpret these abstract recommendations with more concrete annotations that meet the nuances of the technology stack they’re working in. The same process is required to help developers create projects compliant with data regulations, as it’s difficult to take this high-level advice into practice. Translating these requirements into more readable terms is an excellent way to de-silo security and development teams.

    3. Shift Smart

    In recent years, there’s been a lot of talk about shift left. The idea is that to reduce security threats later on, organizations need a tighter grasp on security earlier in the software development life cycle. Shifting security left is often enabled with tools that hold code accountable for potential threats using automated analysis.

    However, Williams sees this as an area where organizations need to be careful. Not all security tools are developer-friendly and might introduce inefficiencies at scale. Instead of shifting left, he advocates for “shifting smart” to introduce security at junctures where it’s most efficient. “You don’t want to shift all security left—you want to shift right too,” explained Williams. “Spread it out over the whole life cycle.”

    4. Avoid Added Steps

    There’s more than one way to bake a cake. Similarly, there’s more than one way to cook up a great software application. As such, most organizations are dealing with multiple tools, making it harder to apply security consistently across all stacks.

    Security should be catered to the specific tooling and processes being used, Williams explained. But that requires answer certain questions like where is a software development team in their journey? Are they waterfall or Agile? How does each CI/CD pipeline behave?

    Obviously, there are many unique factors to consider. Ideally, tooling should be flexible enough to attach itself to existing infrastructure, Williams said, instead of adding additional steps to an already sprawling tooling ecosystem.

    5. Take Security Seriously

    And, of course, there’s the cultural element. “It’s 2022, and companies still don’t take security seriously—they need to change,” said Williams. “It doesn’t matter how they get there—that they get there matters most.”

    Admittedly, cultural change is a slow evolution and the best way to advance will be to add practices and technologies progressively over time. Thus, Williams recommended iteratively inserting pieces, measuring outcomes and proving value along each step of the journey.

    6. Update Outdated Tools

    WhiteHat Security found the average time it took to fix critical vulnerabilities in the spring of 2021 was 205 days. But such a long timeline is at odds with the pace of new threats and the need to patch them quickly.

    The industry is changing the way they do AppSec, said Williams. Traditional DevSecOps security tools, he said, such as static analysis tools, dynamic analysis tools and web application firewalls, are outdated and less accurate compared to newer technologies like interactive application security testing (IAST) and runtime application self protection (RASP). Accuracy, speed and scalability will be important characteristics for security automation tools that don’t require additional human intervention or produce too many false positives.

    DevSecOps Is Still Maturing

    A healthier DevSecOps practice aims to decrease the “vulnerability escape rate,” as Williams called it. Hopefully, by providing instant feedback on designs, engineers will learn not to repeat the same mistakes, thus decreasing the number of vulnerabilities they introduce.

    In summary, DevSecOps is still maturing. Looking to the future, a stronger DevSecOps approach will require a more open attitude to mitigate threats. It also requires practical guidance as not all top-down guidelines translate well into the active development environment. Applications will require proper code hygiene, and the software supply chain itself must be protected, too, in addition to conducting active monitoring of production environments.

  • Participate in the Checkmarx 2020 Survey

    Participate in the Checkmarx 2020 Survey

    Checkmarx, the global leader in software security solutions for modern enterprise software development, and devopsy.kinsta.cloud are conducting a survey about the implementation of DevOps and related automation and security tools.

    The purpose of the survey is to help organizations evaluate their DevOps maturity, find out what are the most used DevOps tools and the most common challenges organizations are facing with their current DevSecOps model.

    The survey consists of 16 short multiple-choice questions. The results will depend on several factors including:

    • The organization’s progress on their DevOps adoption journey.
    • The role of the respondents in their organization and their responsibilities for DevOps transformation.
    • Automation and security tooling capabilities respondents are using for DevOps and cloud-native applications.
    • The respondents’ ability to overcome challenges and obstacles standing in the way to successfully implementing DevOps.

    We urge everyone in the DevOps space to participate in this survey. The more data we can gather, the more we’ll find out about the adoption of DevOps and AppSec tools. We’re counting on you to make this report even more valuable. Invite your friends and colleagues to contribute to the survey, too — the more the merrier.

    Click on this link to complete the survey.

    We will make an announcement when the report is ready. Stay tuned!

  • Best of 2018: 5 Open Source SIEM Tools Worth Checking Out

    Best of 2018: 5 Open Source SIEM Tools Worth Checking Out

    As we close out 2018, we at devopsy.kinsta.cloud wanted to highlight the five most popular articles of the year. Following is the second in our weeklong series of the Best of 2018.

     

    Security information and event management (SIEM) is the cornerstone of IT security. All other network solutions are merely data flows that feed into an organization’s SIEM. Not all SIEMs are created equal, and their capabilities can vary wildly. Choosing the right one for your needs can mean the difference between detecting a security weakness and becoming just another statistic.

    A SIEM solution is a combination of a security event management (SEM) system and a security information management (SIM) system. SEMs monitor servers and networks in real time, while SIMs store the data.

    Both SEMs and SIMs provide analysis. SEMs focus on real-time event correlation, alerting and those fancy network operations center (NOC) “something has gone wrong” dashboards that one may come across in the movies. SIMs focus on bulk data computational analysis (BDCA) of large quantities of logs.

    In other words, a SEM is designed to tell you when something is going down as it happens, and SIMs are designed to spot the subtle attacks that SEMs don’t catch. Merging the two into a SIEM solution seems like a natural fit.

    Related Content:

    The Value of Commercial Open Source

    How Developers Can Take a More Proactive Approach to Security

    SIEM stacks usually consist of at least three components for data collection, data storage and data analysis. The data in question is frequently log files, but can also be netflow traffic or other real-time data feeds.

    There are a number of SIEM tools on the market, both open source and commercial. With the rise of DevOps, containers and other modern application development methods, the open source solutions are seeing a resurgence of interest. Let’s take a look at some of the top open source SIEM tools out there.

    OSSEC

    OSSEC is a popular host-based intrusion detection system (IDS) that works with Linux, Windows, MacOS and Solaris, as well as OpenBSD and FreeBSD. OSSEC is composed of two components: the host agent (responsible for collecting the logs) and the main OSSEC application (responsible for processing the logs.)

    There is also a now-deprecated GUI, but since other open source solutions do a better job of data visualization, the OSSEC project recommends using those solutions instead. Popular open-source data visualization tools include Kibana and Grafana.

    OSSEC directly monitors a number of parameters on a host. This includes log files, file integrity, rootkit detection and Windows registry monitoring. OSSEC also can perform log analysis from other network services, including most of the popular open source FTP, mail, DNS, database, web, firewall and network-based IDS solutions. OSSEC can also analyze logs from a number of commercial network services and security solutions.

    OSSEC has a number of alerting options and can be used as part of automated intrusion detection or active response solutions. OSSEC has a primitive log storage engine. By default, log messages from host agents are not retained. Once analyzed, OSSEC deletes these logs unless the <logall> option is included in the OSSEC manager’s ossec.conf file. If this option is enabled, OSSEC stores the incoming logs from agents in a text file that is rotated daily.

    Whether OSSEC counts as a “full” or “proper” SIEM is the source of numerous internet debates. OSSEC does the hard work of a SIEM: It collects data and analyzes it. OSSEC is at the core of a number of other SIEM solutions, and part of any number of application stacks that pair OSSEC with a more advanced long-term log retention system and advanced visualization capabilities.

    Snort

    Snort is a popular network-based IDS. Network-based IDS systems differ from host-based IDS systems in exactly the way one might expect—while a host-based IDS lives on an individual server or endpoint, network-based IDS systems live further out on the network, and scan all traffic that they can see.

    Snort’s purpose is to sniff, log and perform real-time analysis on network flows. It can display a real-time stream of packets to a console, dump packets to a log file or perform analysis.

    Snort relies on output plugins to determine how and where it will store the information it generates. Snort can store this information in a flat text file, output to a database, a Unix Socket, a pager or cell phone and any number of other destinations.

    Snort has a number of filtering and pattern matching options. This means that snort doesn’t have to display, log or analyze all packets traversing a network link. It can restrict itself to information pertaining to a specific host or matching specific patterns—something that is of increasing utility as network throughput of 100Gbps on individual network links becomes more common.

    Configuring Snort requires careful planning. Dumping 100Gbps worth of packets to a flat text file isn’t the best plan, and most organizations aren’t exactly going to be able to afford to ship that kind of data off to a public cloud-based log repository, either. Judicious use of Snort’s filtering and analysis capabilities combined with output plugins are required to make Snort practicably useful.

    With a narrowly configured set of alerts, Snort’s ability to send alerts directly to a cell phone becomes meaningful. A broader set of filters could be used to pass data to a long-term storage repository for more in depth analysis by another tool.

    Like OSSEC, Snort relies on third-party solutions in order to perform visualizations. As one of the earliest network-based intrusion detection solutions available, there are a number of solutions (both open source and commercial) that exist only to visualize Snort data, making the lack of a built-in visualization system somewhat irrelevant.

    Like OSSEC, Snort’s qualification as a SIEM solution is somewhat debatable. Snort collects data and analyses it, and is a core component to more complete SIEM solutions. Snort is also part of any number of application stacks which add log retention and advanced visualization capabilities.

    It is not unusual to see Snort and OSSEC working together to each fill different niches in the grand scheme of data center SIEM needs. It is also perfectly normal to see them deployed independently, especially as part of cloud-native applications, where monitoring needs can be narrower.

    Suricata is a competing open source network-based IDS that is frequently used in place of Snort.

    ELK

    The ELK stack is arguably the most popular open source SIEM tool available, though, like OSSEC and Snort, there is room for debate about whether the ELK stack even qualifies as a SIEM on its own.

    The ELK stack consists of the open source products Elasticsearch, Logstash and Kibana. Logstash is a receiver for log data from virtually any source. It can filter, process, correlate and generally enhance any log data that it encounters.

    Elasticsearch is the storage engine, and is one of the best solutions in its field currently available. Kibana is the visualization portion of the equation, and it is hands down one of the best visualization system the open source community has yet produced.

    Logstash, a part of the ELK stack, uses input plugins to collect logs; however, it also can accept input from more purpose-built solutions such as OSSEC or Snort. Combined, the ELK Stack’s log processing, storage and visualization capabilities are functionally unmatched. The solution is powerful, but that power comes at the price of complexity and a high TCO. Cloud offerings such such as Logz.io offer a hosted ELK alternative.

    The ELK stack forms the core of a growing number of commercial SIEM offerings. These solutions bring expertise in standing up, configuring and managing the applications in the stack. They also may offer canned or easier-to-design filters for Logstash than are available in the native open source solution. Both approaches offer significant added value.

    Prelude

    Prelude is a SIEM framework that unifies various other open source tools. It is the open source version of the commercial tool by the same name. Prelude aims to fill the roles that tools such as OSSEC and Snort leave out.

    Prelude accepts logs and events from multiple sources and stores them all in a single location using the Intrusion Detection Message Exchange Format (IDMEF). It provides filtering, correlation, alerting, analysis and visualization capabilities. The open source version of Prelude is significantly limited when compared to the commercial offering in all of these capabilities.

    OSSIM

    If ELK isn’t the most popular SIEM, then OSSIM likely wins the crown. The open source version of Alien Vault’s Unified Security Management offering, OSSIM is a framework like Prelude. OSSIM combines its native log storage and correlation capabilities with numerous open source projects to build a complete SIEM.

    The open source projects included in OSSIM include FProbe, Munin, Nagios, NFSen/NFDump, OpenVAS, OSSEC, PRADS, Snort, Suricata and TCPTrack. The inclusion of OpenVAS is of particular interest, as OpenVAS is used both for vulnerability assessment by correlating IDS logs with vulnerability scanner results.

    Like Prelude, the open source OSSIM is not as feature-rich as its commercial sibling. Both solutions work fine for small deployments, but experience significant performance issues at scale, ultimately driving organizations towards the commercial offerings. Log management capabilities in the open source version of OSSIM, for example, are virtually nonexistent.

    Conclusion

    A complete SIEM solution includes the ability to collect information from various data sources, store the data long term, perform analysis on that data and visualize it in useful ways. There are no clear open source winners that deliver all capabilities.

    When selecting an open source SIEM you are either going to have to use feature and performance limited solution designed to drive organizations into the arms of a commercial solution, or you are going to have to combine multiple open source projects to achieve your goals.

    Consider the ELK stack as an example. On its own, the ELK Stack can be a high-quality SIEM solution. Its input filters include public cloud infrastructure monitoring capabilities the other open source solutions can’t match.

    That said, the more dedicated collection and analysis tools, such as OSSEC and Snort, can be far more powerful when dealing with on-premises solutions. These solutions can be combined. OSSEC and Snort can feed the ELK Stack, creating a more complete solution that meets the needs of the majority of organizations.

    Open source SIEM solutions—in whole or in part—are versatile and powerful. They require experience, expertise, and above all time to deploy properly. It is for this reason that commercial offerings dominate the SIEM landscape, even when open source tools lie at the core of those commercial offerings.

    Having 80 percent of your SIEM solution handled for you is better than having to do all of it yourself. Commercial solutions handle installation, basic configuration and provide filters, correlation configurations and visualisation designs for the most common use cases. Don’t underestimate the value of these commercial features: There are a seemingly unlimited number of things to monitor in today’s data centers, and none of us have time to manually configure applications to watch them all.

    — Daniel Berman