staging-devopsy.kinsta.cloud

Tag: cyberattack

  • Checkmarx Report Highlights Need for AppSec Collaboration

    Checkmarx Report Highlights Need for AppSec Collaboration

    A research report published by Checkmarx finds the same basic malicious software developed using multiple programming languages as cyberattackers industrialize their malware development processes.

    Checkmarx, a provider of code scanning tools, shared examples of malicious packages written in multiple programming languages. These example packages share the same indicators of compromise that have gone undetected for years. A “junkeldat” PyPI package for Python applications, for example, that has been compromised also shows up in a Ruby version of the package.

    Tzachi Zornstain, head of supply chain security for Checkmarx, said much like any other development team that uses multiple programming languages, it appears cybercriminals are also sharing techniques. These examples highlight the need for development teams to share security intelligence even if they build applications using different programming languages, he added. There is a tendency for development teams using one programming language to ignore application security issues that appear to only impact applications written in another programming language, noted Zornstain.

    The fact that the packages remained undetected for such a long period of time is due—at least in part—to the lack of information sharing in the ecosystem, said Zornstain.

    Cyberattackers are, of course, trying to take advantage of the implicit trust many development teams have in open source projects. However, now that more cybercriminals are making a concerted effort to compromise downstream software components, it’s imperative that every component be vetted, said Zornstain. In fact, organizations should not use any code provided by strangers, he advises.

    The core issue is that many open source projects are maintained by a small number of programmers contributing their time and effort to building components that others are free to use. Many of them argue that the onus for making sure software is secure is on the organizations that decide to deploy that software. Nor is it their responsibility to keep track of cybercrimimals distributing malicious versions of their software.

    Unfortunately, many IT vendors and large enterprise IT organizations that rely on that code are, unfortunately, not contributing anything meaningful back to the project, either in terms of financing or helping open source maintainers find and remediate vulnerabilities. Many of those same organizations, however, are assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions. As a result, it may be only a matter of time before these long-simmering open source software security concerns boil over into a larger crisis.

    One way or another, DevSecOps best practices will need to be applied to application development at a deeper level. Organizations can’t assume that the software components they are relying on have been scanned for vulnerabilities by someone else. It’s simply too easy for a development team to make a mistake. The need for higher levels of security may lengthen the development process, but the alternative—malware infestations wreaking havoc—is far less desirable.

  • The New Norm for Modern Apps: Security Observability

    The New Norm for Modern Apps: Security Observability

    Observability has burst onto the scene across all types of operational and security-focused activities. Its need is being driven by increased demands for businesses to be more responsive to changes and more proactive when dealing with potential problems. In particular, security observability holds the promise to help reduce the time to detect a cyberattack. And going a step further, it can help detect security vulnerabilities before an attack even occurs.

    What is security observability?

    In the past, most operations relied on visibility into their systems and applications to manage security. Visibility would be achieved via monitoring applications, systems, and their logs. Monitoring solutions would collect and analyze information to detect suspicious behavior or unauthorized system changes. And having defined which types of behavior should trigger alerts, solutions would take action as needed.

    Perhaps more to the point, monitoring lets you detect a known set of problems or conditions. Thus, it is essential for alerting and analyzing long-term trends. Simply put, monitoring lets users know how their systems and applications are functioning and being used.

    However, the problem with security monitoring of complex distributed applications is that it is a passive approach to highly dynamic operations. And it often does not provide any insights into root cause problems or anomalies that might be precursors to problems in the making.

    Security observability expands on monitoring by enabling correlation and inspection of the data to provide much deeper insights. Observability typically requires logs, metrics, and deep tracing. All data is used for modeling and analytics. Companies can mine the data, look for patterns, use artificial intelligence and machine learning to remediate problems and proactively defend against problems.

    Why security observability is needed now

    The need for security observability is growing due to the way applications are developed.

    The general industry trend is a move to cloud-native architectures based on microservices. Such an approach brings many benefits. Applications can scale quickly. Companies can easily change or update a small aspect of a larger application without impacting the rest of the app. And businesses can make use of new technologies. For example, a business can add a new front-end or implement more sophisticated AI or machine learning modeling.

    Such a development approach can introduce potential blind spots and complexity. In particular, modern applications built using cloud-native architectures and microservices introduce new challenges. The loose coupling of such applications, their distributed nature, and increased complexity makes it harder to understand vulnerabilities. As a result, traditional cybersecurity approaches break down. They miss the interactions and inter-dependencies of the many elements that comprise modern applications.

    Furthermore, traditional security monitoring solutions can be limited. For example, visibility often must be split across tools resulting in insecure platforms or situations where relevant data is not even used in monitoring.

    Adding to the security challenges is the widescale embracement of low-code/no-code development methodologies. Such technologies open development up to business units and citizen developers. These groups can build sophisticated applications, often with little oversight or guidance. As a result, apps may be created by assembling building blocks that may be outdated, unpatched, or simply have vulnerabilities.

    DevSecOps needs security observability

    With all these trends, it is not surprising that businesses are exploring new approaches to security. Just as quality assurance was melded into development processes using automated testing, security ops are being meshed with development. Hence, the rapid implementation of DevSecOps methodologies in organizations today.

    While security issues can grow when using cloud-native development methodologies, there is a lesser-known security benefit. Applications and services constructed using APIs and microservices have an advantage over other systems because developers and security staff can more easily observe what’s happening inside them. In addition, businesses can add links to the APIs and microservices and use tools to collect the details of such operations.

    Given this wealth of data, security observability expands on monitoring. Rather than just detecting vulnerabilities and incidents that raise compliance issues in the development process, DevSecOps using security observability, seeks to identify issues and automatically take corrective actions.

    Moving forward, businesses should expect more adoption of DevSecOps and more automation based on security observability. This will only serve to strengthen security and compliance across systems and applications.

  • Best Practices for Cloud Incident Response

    Best Practices for Cloud Incident Response

    Cloud computing is now mainstream, with almost all organizations running at least some resources in the public cloud—whether software-as-a-service (SaaS), platform-as-a-service (PaaS) or infrastructure-as-a-service (IaaS). Security teams have been scrambling to adapt to cloud environments, and with the growing adoption of DevSecOps, they are working together with DevOps teams to secure cloud systems from the ground up.

    As your organization discovers the best way to secure its cloud investments, you also need to develop an incident response strategy for the cloud. Even if your cloud security controls are perfect (and they aren’t), attacks will happen. Knowing what to do during an attack and preparing teams for incident response can be the difference between an incident quickly contained and resolved, and a multimillion dollar disaster.

    What Is Incident Response?

    Incident response enables organizations to make sure they are aware of security incidents and can respond in time to limit the damage to their systems. The objective is to block attacks and prevent similar attacks in the future.

    The SANS Institute’s six-step incident response process provides a structured framework for security incidents. These steps are:

    Prepare—establish security policies, carry out risk assessments, determine which assets are sensitive and establish an incident response team.
    Identify—monitor your systems to detect anomalous activity, identify real security incidents and investigate the severity and type of threats.
    Contain—conduct short-term containment procedures to stop the spread of the threat, followed by long-term containment, such as applying temporary fixes and rerunning a clean system.
    Eradicate—identify the root cause of the incident, remove malware and implement measures to prevent future attacks.
    Recover—restore your production systems and apply measures for preventing further attacks. Test and monitor recovered systems.
    Learn—perform retrospective analysis within two weeks of the incident with complete documentation evaluating containment efforts and determine how you can improve the incident response process.

    How to Prepare Your Cloud for Incident Response

    There are several ways you can prepare your incident response team and your cloud environment for more effective incident response:

    Establish response goals—determine incident response objectives in consultation with stakeholders, legal advisors and organizational leaders. Common goals include problem control and mitigation, restoration of affected resources, and storage of data for evidence and attribution.
    Use the cloud to respond—ensure your cloud resources include the tools and resources you need to respond to an incident. For example, ensure you have robust cloud-based logging and monitoring systems, and set up cloud-based backup and disaster recovery so you can rapidly restore affected systems.
    Determine your requirements—keep copies of logs, snapshots and other evidence in a centralized cloud account. Apply mechanisms to enforce retention policies. Use tags and metadata to maintain visibility and connect logs and cloud resources to organizational units, projects or corporate systems.
    Use a redeployment mechanism—if a security anomaly is caused by a misconfiguration, you should be able to remediate it easily by redeploying the resource with the appropriate configuration. Ensure the response mechanisms can be executed multiple times if necessary.
    Leverage automation—after identifying recurring problems and incidents, automate as much as possible and break them down programmatically to build response mechanisms for common situations. For example, use the mature auto scaling service on AWS or Microsoft Azure’s infrastructure-as-code (IaC) capabilities. This is much easier on the cloud than it was in an on-premises data center. Ensure you use human response only for unique, new or critical incidents.

    Effective Incident Response in the Cloud

    Use the following tips to improve your ability to respond to security incidents in a public cloud environment.

    Shift Your Focus

    Cloud environments require you to monitor different elements than you would in traditional on-premises environments. In the cloud, you should focus on applications, APIs and user roles. Consider how incident responders can operate successfully in a cloud environment, and what tasks they may need to perform. The incident response team must have proper access and visibility into your systems so they can detect, remediate and prevent attacks.

    Integrate Alerting and Incident Management Tools

    The security team must have direct access to supporting data to triage alerts and classify incidents. To this end, security alerting tools should be integrated with any incident management tools you use, like PagerDuty and Slack, for example. This enables security alerts to directly reach the existing tools and workflows used by your teams. Responders won’t have to alternate between tools to see what is happening.

    Build an audit trail to capture the response to each alert, which will provide visibility and accountability and help you refine your response processes. All actions taken in security tools must be visible in the relevant collaboration tool, so you can see who dismissed a specific alert and when, and what annotations they made.

    Work with Your Cloud Provider

    Cloud providers usually have an incident response team, but you cannot assume the vendor will handle everything during an event. Be aware of the shared responsibility model, where cloud providers are responsible for securing the infrastructure, while the customer is responsible for data and workloads.

    Make sure you understand the service agreement for your cloud provider and who is responsible for exactly which element of the response. Find out exactly what alerts you can expect from the vendor’s team and how it can support your own team. Having a clear relationship and establishing points of contact can save critical time during an incident.

    Protect Your Logs

    The major cloud vendors provide logging capabilities for their environments, including log files or operational metrics to provide insight into service operations. Logging services may be free or paid, ranging from basic access logs to complete audit and configuration logs. Most cloud logging service will allow you to store logs outside the cloud or on-premises—and it is critical to do so.

    Logs are a useful resource for incident response investigation, and you must ensure they remain inaccessible to attackers. An attacker might be able to compromise your cloud system or services, but they won’t be able to modify or delete your logs. Logs are a protected source of information that can help you identify the attack timeline, targeted systems and the attacker’s IP address. This provides a reliable starting point for investigations.

    Conduct Cyber Range Training

    Organizations often rely on exercises to train or test their security and incident response capabilities. Today, cloud environments provide an opportunity to simulate your production network in a protected environment, allowing your security team to practice their response to real attacks on your network within a safe setting.

    Tools such as AWS CloudFormation allow you to quickly design and deploy training networks that are identical to your actual network. You can keep costs down by limiting the duration of exercises. These exercises may be the best way to prepare your team to respond to attacks in the real world.

    These are the basics of security incident response, preparing a cloud environment for incident response and how teams can effectively react when the inevitable attack occurs. In short, it’s important to:

    Focus on what matters – In the cloud, this is APIs, applications, and identity and access management (IAM) systems.
    Integrate alerting and incident management tools – The cloud provides ample automation capabilities. Use them to respond automatically to common anomalies.
    Work with your cloud provider – You are not alone in the cloud, and teams need to understand exactly which part cloud providers will take in responding to an incident.
    Protect your logs – If logs are exposed to tampering, you will have no way to detect, investigate and respond to attacks. Protect them at all costs.
    Conduct cyber range training – You’ll never really know what it’s like to respond to an incident until one actually happens. Instead of waiting for a real attack, conduct a “cyber range training” or security drill and see how everyone works together in an attack scenario.

    Now, you’ll be better prepared as you move towards a cohesive cloud security strategy for developers, operations, and security teams.

  • Cybersecurity 2021: Are You Really Prepared for a Cyberattack?

    Cybersecurity 2021: Are You Really Prepared for a Cyberattack?

    As the majority of businesses are increasingly moving to the online world, employees keep working remotely and more cyberattacks keep happening all over the globe, there is no doubt that embracing DevSecOps should be the new normal for every company. Organizations need to be able to adopt DevSecOps practices and adapt to new and evolving threats in order to protect their data and systems from malicious attacks.

    At Cybersecurity 2021: The New Normal Virtual Summit, taking place March 4 and 5, the brightest minds in the security and IT industry will come together to discuss new security threats, empower DevOps teams with the latest security tools and provide practical tips and guidance to help developers and ops teams make the right security decisions to keep their data secure.

    The two-day virtual event features thought-provoking discussions, networking opportunities and educational sessions focused on:

    • DevSecOps tools and practices
    • The main challenges of security and development teams when it comes to AppSec
    • Identity and Access Management (IAM)
    • Passwordless and the long-term future of identity management
    • Policy-as-Code and how it impacts security
    • How security threats changed with COVID-19 and what to expect in 2021
    • How to manage AppSec
    • How to mitigate API vulnerabilities
    • How to break the silos and advance towards DevSecOps maturity
    • How to expand your security program through low-to-no cost initiatives
    • Time series database for security monitoring
    • Machine identity management
    • Top 10 Hacks From the Past Decade
    • Runtime observability techniques for security and compliance
    • Securing AWS credentials on DevOps machines

    Cybersecurity 2021 features an outstanding lineup of industry leaders, including:

    • Ira Winkler, author and president at Secure Mentem
    • Chenxi Wang, founder and general partner at Rain Capital
    • Ron Gula, president at Gula Tech Adventures
    • Richard Stiennon, founding member of The Analyst Syndicate and chief research analyst at IT-Harvest
    • Joe Levy, CTO at Sophos
    • Rajat Bhargava, founder and CEO at JumpCloud
    • Myla Pilao, head of security research communications for TrendLabs at Trend Micro
    • Upasna Gupta, senior product marketing manager for Prisma Cloud at Palo Alto Networks
    • Julian Waits, general manager of cyber business unit and public sector at Devo
    • Joseph Feiman, chief strategy officer at WhiteHat Security
    • Ian Murphy, founder and CEO at CyberOff
    • Mike Jones, security researcher at H4unt3d Hacker Podcast
    • Rhys Arkins, director of product management at WhiteSource
    • TJ Jermoluk, co-founder and CEO at Beyond Identity
    • Jim Ducharme, general manager of the anti-fraud business unit at RSA

    Attendees will have the chance to enter a raffle for a chance to win a free copy of “You can Stop Stupid” by Ira Winkler and another one for a free copy of “Security Yearbook 2020” by Richard Stiennon. There will be valuable resources available for download and attendees will be able to interact with sponsors to learn more about their security tools and services.

    To see the full agenda and to register, please visit the Cybersecurity 2021 website.

  • Meeting the Need for Speed in Cyber Threat Response

    Meeting the Need for Speed in Cyber Threat Response

    In the very early days of the internet, hackers most likely were “lone wolves.” They might be an unhappy customer, a disgruntled employee or a tech-savvy youth who just wanted to see if he could breach a target’s defenses.

    Occasionally, hackers might aspire to more devious crimes including identity theft, blackmail, theft of trade secrets, exposure of personal information or monetary theft. These types of hackers were annoying, unnerving and potentially dangerous, but they seldom caused widespread damages or serious financial losses. Today, however, cybersecurity professionals face an entirely new group of hackers and an escalating number of attacks—and security strategies and tools have not been able to keep pace.

    The Modern Hackers

    The greatest source of risk comes from well-financed, sophisticated hackers who often are connected to a government that sanctions and supports their activities. These groups constantly refine their already impressive skills and they are patient as well as persistent. They know how to circumvent defenses that rely on signatures or pattern matching, and they are adept at launching attacks that may take months to achieve fruition.

    For example, sophisticated hackers may launch an upstream attack aimed at companies that make the products that others use for security, including SSL certificates and other digital credentials. These credentials are then used to steal money, intellectual data or other information from the group’s real targets. Hackers can also attack in stages, such as first going after information that will give them access to an organization’s network, allowing them to conduct whatever mayhem they want on their own schedule. They may install an encrypted “zero day” attack, for instance, or simply wait until a desirable piece of intellectual property is completed.

    Why Speedy Responses Are Essential

    The longer that a breach goes undetected, the more damage the incident will cause. It is a bit like having an undetected roof leak; the longer the leak allows water to penetrate beneath the roof, the more damage the water will do to the structure.

    Unfortunately, most organizations are not doing a very good job of detecting breaches quickly. In 2014, the Verizon Data Breach Investigations Report revealed that 43 percent of all web application attacks were not discovered for months, and 85 percent of the point-of-sale intrusions went undetected for weeks. Other breaches have gone without detection for years, such as the Excellus breach that lasted 18 months and the allegedly state-sponsored “Project Sauron” attack that was in operation for almost five years.

    When attackers have months or years to access a victim’s network, they have ample opportunity and time to inflict a substantial amount of damage. They can even expand their attack to infiltrate the networks of the original target’s customers or vendors. Interestingly, a study conducted by the Ponemon Institute found that approximately 33 percent of all attacks were not detected for two years — and two-thirds of the attacks were discovered by a third party rather than the compromised organization.

    However, a report issued in June 2016 by the Business Continuity Institute indicates that many organizations are making progress when it comes to responding to cyberattacks. BCI surveyed 369 organizations in 61 countries. Approximately 66 percent reported that they had suffered at least one attack during the previous 12 months, and 15 percent reported that they had suffered 10 or more attacks. Roughly 31 percent claimed that they responded to attacks within an hour, but 19 percent said that they took at least four hours to respond. Approximately 24 percent were hit by a denial-of-service attack, while 45 percent suffered a malware attack; both forms of attack rendered the organization’s network inoperable or contaminated.

    Responding Quickly to Attacks

    Although most cybersecurity professionals know that response time is critical, not all of them understand the best ways to ensure that the speed is there when needed.

    • A speedy response starts with an effective incident response plan. The plan should be based on a thorough assessment of threats, risks and potential failure modes, and it should be updated frequently and available to all parties.
    • “Practice makes perfect.” Response teams should have ample opportunities to practice their tasks through frequent “dry runs.” Instead of wasting time trying to determine what they should do when an attack does happen, they can react reflexively.
    • Automation can greatly reduce the amount of time required to respond to an incident. For example, without automation, if a breach occurs, staff members might have to manually check 5,000 or more endpoints. However, an automation platform can collect, analyze and report on the activity in much less time.
    • Increase visibility across the different domains and systems. A recent survey of IT remediation teams conducted by the SANS Institute revealed that almost half felt that the lack of visibility was their main impediment to an effective, speedy response. Using a security information and event management (SIEM) solution for log aggregation and correlation can increase visibility across organization.

    When the health of your organization is at risk, taking even an hour to respond to an incident can be far too long. Taking a day, a week or a month to detect and respond to a threat can do irreparable damage. With steps in place, organizations can meet their need for speed in addressing cyber threats quickly, to best protect their networks.

    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.

  • From a Commodore 64 to DevSecOps

    From a Commodore 64 to DevSecOps

    We all know the story: a farm, a kid, a Commodore 64, and a modem maxing out at 300bps. A few unexpected phone bills later, and young Ian Allison is figuring out how to game the system so he can keep using his newfound gateway to the world of tech. According to Ian, that is where he began building the foundation of skills for his career in computer security.

    At the recent All Day DevOps conference, Ian (@iallison), now with Intuit, talked about his history of being “that” security guy. You know, the one who thinks developers don’t care about security or deadlines and, really, are just plain “stupid.” But, don’t worry, he is enlightened now and realizes that we all have the same goal: Everyone wants to build a secure system.

    Ian realized that “security doesn’t understand how developers or operations works. Security solves for security, but that leaves everyone else in their own place.” He started his enlightenment when his career path led him to a place called DevSecOps; that is, DevOps where security plays a more integral role.

    Ian pointed out that traditional InfoSec relies on compliance, regulations, appliances and perimeter (CRAP). He then realized the selfishness of his own and his peer’s perspective: Remediation is left up to the developers, the feedback they get are 200-page scanner reports, and it only solves problems for security and compliance. It doesn’t help developers reach their shared goal of a secure system.

    DevOps creates an opportunity for security to get a better view into our infrastructure, operations and development efforts.  DevOps is not only fast, lean and efficient, but when done right, it is also collaborative and empathetic. Couple speed with collaboration and empathy, and DevSecOps can blossom.

    Here is the reality that Ian was facing: Scanners find the absolute bare minimum; bad default configs are a HUGE problem even with SaaS vendors; manual testing can uncover defects that have been hiding for year; and the attackers are more skilled and motivated.

    How do you implement it and make it better?

    • Allow Dev teams to assume the risk of their decisions.
    • No more Security exceptions or signoffs.
    • Security is everyone’s responsibility.
    • Test the crap out of your own stuff like an attacker would.

    At Intuit, Ian wanted to help build stronger bridges between development, operations and security teams.  To do this, he set up a Red Team to:

    • Use same tactics as attackers.
    • Only scope is “Don’t take down production.”
    • Need to adapt and evolve like an attacker.
    • Prove risks actually exist.
    • Should be writing their own exploits.
    • Should have ongoing campaigns that mimic attackers.

    The Red Team started small and lean and focused on the cloud. It worked like an Agile DevOps team, working manually with the use of some tools. In the end, the team found, reported and fixed thousands of vulnerabilities not found by scanners.

    Ian goes into more details and lessons learned in his full All Day DevOps conference session (just 30 minutes). The other 56 presentations from the All Day DevOps Conference are also available online, free-of-charge here.

    This blog series is reviewing sessions from the All Day DevOps conference from November which hosted more than 13,500 registered attendees. Last week I discussed, “System Hardening with Ansible.” Next week, look for my review of an awesome session by Erlend Oftedal:  “There is No Server: Immutable Infrastructure and Serverless Architecture.”

    — Derek E. Weeks

  • Elasticsearch Ransomware Attacks Highlight Need for Better Security

    Elasticsearch Ransomware Attacks Highlight Need for Better Security

    Recently, reports surfaced that a large number of Elasticsearch servers fell victim to potential ransomware attacks. Ransomware is the type of malware a company doesn’t want on its systems or network. It takes systems hostage, most commonly by encrypting or stealing data, and exposes the owners to blackmail attempts. According to a report by the Herjavec Group, the cost of damages from ransomware was projected to reach $1 billion by the end of 2016.

    A new wave of ransom attacks observed over the last several weeks targets unsecured MongoDB databases. Security researchers Victor Gevers and Niall Merrigan call these attacks a “ransack,” and Merrigan estimates that more than 40,000 databases were impacted in the first two weeks alone.

    Now research shows that Elasticsearch servers, which are configured to be insecure so they can be accessed over the public internet, are being subjected to similar ransom attacks. Victor Gevers tweeted that within the first three days, 2,515 Elasticsearch servers were eradicated and ransomed and 34,298 vulnerable Elasticsearch instances are still open. In the following days, the number of affected servers has risen to more than 5,000. John Matherly, founder of Shodan, tweeted that the vast majority of vulnerable Elasticsearch servers are open on Amazon Web Services (AWS).

    If an Elasticsearch server is hacked, users will find data indices gone and a message that reads: “SEND 0.2 BTC TO THIS WALLET: 1DAsGY4Kt1a4LCTPMH5vm5PqX32eZmot4r IF YOU WANT RECOVER YOUR DATABASE! SEND TO THIS EMAIL YOUR SERVER IP AFTER SENDING THE BITCOINS…”

    The FBI stresses that victims should refuse to pay Bitcoin ransoms, so users might or might not get their data back depending on the security processes they had in place in case of an attack. At this point, it is unclear who is behind the attacks.

    Ironically, what makes these attacks possible is not that Elasticsearch in itself is insecure, because it isn’t. Ransom attacks are possible because these instances have been configured in a way that makes them vulnerable. It’s like leaving the front door open.

    Technology journalist Steven Vaughan-Nichols of ZDNet gave an excellent summary, explaining that, when used by amateurs without any security skills, Elasticsearch is simple to crack. The people deploying instances on AWS clouds are under the impression that AWS is protecting them, but that’s not the case. While AWS tells users how to protect their AWS Elasticsearch instances, users still need to do the work themselves.

    He notes: “The worst thing about this? Just like the MongoDB attacks, none of this would have happened if its programmers had protected its instances with basic, well-known security measures.”

    Elasticsearch is often used in log management, typically as part of the Elastic Stack or ELK, which stands for its main open-source ingredients of Elasticsearch, Lucene and Kibana. Since it’s free, open-source software, ELK is an easy first choice for many. It’s a great, powerful piece of software. These open-source projects are highly active, with thousands of code contributions every month and a growing combined code base of about 2.5 million lines of code.

    Users need expertise to deploy and run it efficiently and safely, though, and that means needing people in an organization with the skills and time to maintain ELK clusters. If these people leave, companies need to have a backup. If they aren’t willing or able to invest in these resources, they are likely to get into trouble, like this latest ransom attack situation illustrates.

    ELK is free software, but keep in mind what Richard Stallman, founder of the Free Software Foundation and the GNU Project, has to say about free: “’Free software’ is a matter of liberty, not price. To understand the concept, you should think of ‘free’ as in ‘free speech,’ not as in ‘free beer.’”

    Whether a company pays for a log management service or runs ELK, one approach isn’t necessarily better than the other. For some companies, it makes a lot of sense to run an in-house-built log management solution based on ELK, or even one built from scratch. For others, a delivered solution may be best.

    Regardless, companies and teams need to carefully evaluate if open source makes business sense and if they are realistically able to properly support the deployment without imposing risks. If these factors aren’t weighed or completed correctly, the number of Elasticsearch ransomware attacks will continue to grow and be a profitable endeavor for hackers.

    About the Author / Sven Dummer

    Sven Dummer is the senior director of product marketing at Loggly. Previously, Sven worked with Yahoo, Wind River (acquired by Intel), SUSE, and Microsoft in product development and management. At Intel, Sven also helped launch (and named) the collaborative Yocto Project, an open-source initiative that enables users to create custom Linux-based systems for embedded products regardless of the hardware architecture. Connect with him on LinkedIn and Twitter.

  • Network Resilience and Security from A to Z

    Network Resilience and Security from A to Z

    An observer watching a bunker shot by legendary pro golfer Gary Player was heard to say: “I’ve never seen anyone so lucky in my life.” The player retorted: “Yes, and the more I practice, the luckier I get.” Yet, when it comes to cybersecurity, nearly half of organizations are solely relying on luck to get them through a cyberattack.

    There is not enough practice or training in terms of incident response, and testing happens haphazardly depending on the developer and organization—obfuscating baselines and the context necessary to ensure security and resilience. Particularly in terms of testing, we’ve noticed that despite awareness of its importance, bugs and vulnerabilities routinely slip through. In fact, a recent Ixia survey found that 34 percent of developers have deployed products that have had a few bugs. Worse, 31 percent said products harbored significant vulnerabilities that required patching later in the cycle when shipped.

    The problem has been exacerbated by the rapidly growing normalization of agile development processes. Groups of developers are tasked to build products piecemeal, leading to application development that is often incremental and happens in iterative cadences. Testing and oversight happen at each step of the process, but the segmented nature of the development cycle means that bugs and vulnerabilities often arise when the code is assembled, and are routinely missed. For instance, the average IT web application had 32 vulnerabilities, according to recent WhiteHat Security report. It’s clear that more than a local test—a comprehensive end-to-end test—and relevant training are critical.

    A Change in Culture

    Improvement begins by changing the culture that minimizes security testing for the sake of launch timelines. Too often, the product development team will come together just to be told they need to move up their release date. The habit results in products that walk a thin line of performance, as they may contain unknown security holes due to not being fully tested. Just consider the slew of IoT devices and services that have been proven to be vulnerable because of this habit—from cars to coffee machines to cameras. It’s a major reason for security incidents, even with multiple layers of security tools.

    This also requires the right training. Having seemingly secure code and the right security measures is not enough for a strong security stance if proper training is not implemented. Organizations need to learn how to respond. Yet, recent SANS Institute research into the incident response capabilities of companies worldwide found that 43 percent of respondents did not have a formalized incident response plan, and 55 percent didn’t even have an incident response team.

    This less-than-vigilant approach to system-level security can have worse implications once a product goes live in the network. For instance, updates, patches and configuration changes applied when a new feature is added can reset an organization’s security posture, and this sometimes goes unnoticed—leaving gaps for threat actors to exploit. Or sometimes a machine fails to update and becomes and entry point, as experienced by JPMorgan Chase. Continuous testing and training from the very onset of operation and throughout a tools lifespan are imperative for all employees, especially IT and security pros—even in its simplest iterations.

    What to Look For

    Successful and continuous testing and training expose security and IT pros to anomalous activity they’d not be able to recognize otherwise. It’s necessary to be able to answer questions such as, “What does suspicious activity look like on my network?” or “What security alerts require immediate action?” The more they see, the more refined their eye becomes—it’s all about a proactive approach paired with repetition.

    Which raises the question, what is considered a good test? It starts with accurately reflecting the widest range of attack types in live operation. It is also important to create an accurate sandbox to test in so that it can be as close to reality as possible. The more accurate the environment, the better prepared IT and security teams will be. Realistic depictions better prepare employees as new malware, phishing and DDoS attack types emerge every day—not to mention it helps keep up with evolving typical application behavior.

    More specifically, function and system testing should be at the heart of any program following the development cycle test process. Quality of service, performance and resilience all benefit, along with security, as a result.

    Some companies take shortcuts, such as using internally generated attacks or crowdsourced probes to attack their networks. Just as bad, some have the development team create and run their own test scenarios. While this can give the illusion that everything is good, it creates a false sense of security—a single scenario only protects you from one type of attack.

    The key is not to stop at the minimum when it comes to security testing and training. Developers spend lots of time building great features; why not spend time training teams on how to use them? Limited or biased tests can easily overlook glaring flaws.

    Ultimately, the right approach to testing can make networks robust and prepare IT teams for real-world attack situations, helping minimize response times and the negative impact on the business. As breaches now seem to be coming from every direction, testing needs to come to the foreground, from the development stages to when products sit directly in the line of fire.

    About the Author / Jeff Harris

    jeffharrisJeff Harris is VP, Solutions at Ixia, leading solutions marketing for Ixia’s security portfolio of products and capabilities. As a former product development leader of advanced networking, communications, and surveillance products for commercial and military applications, Jeff has a deep appreciation for security implications that occur in development and operation. Jeff has led first to market product teams in personal area networks, mobile ad hoc networks, and a wide range of surveillance equipment and platforms. Connect with him on LinkedIn and Twitter.

  • The Cost of Not Building with Security in Mind

    The Cost of Not Building with Security in Mind

    The unfortunate reality for today’s organizations is the fact that a security breach is bound to happen. Major breaches are happening with alarming frequency and fill the news headlines almost daily. And behind many of these major breach stories is a software vulnerability that has been exploited. There is a silver lining, however. Addressing security at the development stage can help organizations “get upstream” of certain issues, which goes a long way toward alleviating potential breaches.

    Now there are always two sides to every coin, and this is where companies need to weigh the costs of not taking a proactive approach to making security a key part of their software development process. Is the upfront time and effort worth it when it comes to developing software and ensuring bugs and vulnerabilities are addressed before it is put into the wild? The simple answer is, yes! We are already seeing this in certain industries such as financial services, which learned the hard way that it is a critical component of software development—mitigating risks and significantly lowering the financial burden associated with a major breach.

    In fact, security should have been more central to software development a long time ago. As software, and more broadly technology, continues to evolve and permeate our lives from more angles, it is crucial that security be a consideration—a “use case” as developers call it—from the earliest conceptual stages of a project. The costs of not doing so are simply too painful to imagine otherwise.

    Shifting to Security-First

    To build more secure software, organizations typically must implement a software security initiative. You can break it down into four steps:

    • Assess your current software assurance posture
    • Define the strategy your organization should take to ensure a viable posture
    • Formulate a road map of how to achieve that posture
    • Implement your strategy

    The above steps are simple and when you think of the alternative to not doing this, adding security as a pivotal part of the software development process seems like a no-brainer. To better understand what I mean, you need only look at the cost the average breach has on an organization. According to the 10th annual “Cost of Data Breach Study” independently conducted by Ponemon Institute, the average consolidated total cost of a data breach in 2015 was $3.8 million, an increase of 23 percent from 2013. The study also reported that the cost incurred for each lost or stolen record containing sensitive and confidential information increased 6 percent, to a consolidated average of $154 from $145. Depending on how much data has been compromised, the financial fallout can be staggering, if not crippling, to an organization.

    Conversely, the cost to repair a single vulnerability in an application during the design phase is less than $500, according to the IEEE Computer Society. The fact that the financial impact of not addressing security during the development process can quickly become cost prohibitive, is a clear indication that secure software development practices can no longer be overlooked. Breaches are now a boardroom issue and require a seat at the development table.

    As we can see from the stats above, the economic fallout for organizations is obvious, but with the Internet of Things coming to a house near you, this issue is suddenly becoming more personal and painful for the average person. Whether an attacker takes over your thermostat from Russia or finds a way to monitor your home via your baby camera, vulnerabilities are making it easier for malicious actors to corrupt corporate, government and now individual networks like never before.

    We are well beyond the “it will never happen to me” phase. Breach stories that used to happen to so called “other” people are more likely to happen to you if software defects continue to be ignored and are not fixed when they should be. No matter how you crunch the numbers, if security isn’t addressed at the software development level, the result will always end in a costly lesson learned.

    About the Author/John Dickson

    John Dickson_HeadshotJohn B. Dickson is an internationally recognized security leader, entrepreneur and Principal at Denim Group, Ltd. He has nearly 20 years hands-on experience in intrusion detection, network security and application security in the commercial, public and military sectors.

    Dickson is a popular speaker on security at industry venues including the RSA Security Conference, the SANS Institute, the Open Web Application Security Project (OWASP) and at other international conferences. He is a sought-after expert and regularly contributes to Dark Reading and other publications. A Distinguished Fellow of the International Systems Security Association, he has been a Certified Information Systems Security Professional (CISSP) since 1998.

    As a Denim Group Principal, he helps executives and Chief Security Officers (CSOs) of Fortune 500 companies and government organizations launch and expand their critical application security initiatives.

    Twitter: http://twitter.com/johnbdickson
    Linkedin: https://www.linkedin.com/in/john-b-dickson-cissp-41a149