devopsy.kinsta.cloud

Tag: SOC

  • Will DevSecOps Replace the Security Operations Center?

    Will DevSecOps Replace the Security Operations Center?

    Traditionally, a security operations center (SOC) is a physical facility where an organization performs information security activities. The SOC team analyzes and monitors the organization’s security systems. A SOC aims to protect businesses from security breaches by identifying, analyzing and responding to cybersecurity threats. 

    The SOC team consists of administrators, security analysts and security engineers. They work in collaboration with internal development and IT operations teams.

    A SOC is a proven method to improve threat detection and incident response, reduce the potential for security breaches and help organizations respond appropriately in the event of an incident. The SOC team isolates unusual activity on servers, databases, networks, endpoints and applications, identifies and investigates security threats and responds to security incidents as they occur.

    SOCs were once considered suitable only for very large organizations. But many small organizations today are building lightweight SOCs, such as hybrid SOCs that rely on a combination of part-time in-house staff and outsourced experts or virtual SOCs that function without physical facilities.

    SOC Challenges

    SOCs play a critical role in protecting an organization’s assets from cyber threats and ensuring the security and integrity of its networks and systems. However, SOCs can face a variety of challenges in their efforts to detect and respond to potential threats, including:

    Alert Overload

    Alert overload is a common challenge faced by SOCs. It occurs when the SOC team is inundated with too many security alerts, making it difficult to prioritize and effectively respond to them. This can be caused by a high volume of alerts, a lack of context or proper prioritization, limited visibility, or limited resources. To address the challenge of alert overload, SOC teams may implement strategies such as tuning security tools, implementing a triage process, utilizing automation, and increasing the size of the team.

    Visibility Gaps

    Visibility gaps refer to areas of an organization’s networks and systems that are not adequately monitored or protected by security tools and processes. These gaps create vulnerabilities that cyber threats can exploit, making it difficult for SOC teams to detect and respond to potential threats. 

    Visibility gaps may be caused by complex environments, limited resources, shadow IT, or misconfigured systems. To address visibility gaps, SOC teams may implement strategies such as implementing a security information and event management (SIEM) system, conducting regular assessments, implementing additional security controls, educating employees and ensuring that systems are properly configured.

    Complex Investigations

    Investigating cybersecurity threats can be a challenging task for SOC teams. It requires them to quickly and accurately identify the root cause of the threat and take appropriate action to contain and mitigate it. This can be difficult due to limited visibility, complex environments, a lack of context or limited resources. 

    To aid in the investigation process, SOC teams may use forensics tools to gather and analyze evidence related to potential security incidents. Common tools include network forensics tools, which allow the team to analyze network traffic and identify the source of a threat and digital forensics tools, which allow the team to examine devices and systems to identify evidence of an incident. 

    Slow Detection and Response Times

    Slow detection and response times are a common challenge faced by security operations centers (SOCs). They can impact the organization’s mean-time-to-detection (MTTD) and mean-time-to-response (MTTR), which measure how long it takes the SOC team to detect and respond to potential security incidents. 

    A high MTTD and MTTR can have serious consequences for an organization, as it may allow a cybersecurity threat to remain active for an extended period of time, potentially causing significant damage.

    What Is DevSecOps?

    DevSecOps stands for development, security and operations. It is a new work process that involves integrating security practices into all DevOps processes. The DevSecOps mindset guides all technical experts equal access to security expertise.

    DevSecOps moves security practices and enforcement early in the development process. This creates a culture where security is everyone’s responsibility, not just that of the security team.

    Building security into every phase of the software delivery life cycle enables continuous integration and high development velocity with fewer security issues and lower compliance costs.

    How DevSecOps Improves Security and Quality

    Organizations using the DevSecOps model understand that security should not be an afterthought and should be a core part of the software development life cycle (SDLC).

    DevSecOps collaboration is more difficult than DevOps because it requires achieving two seemingly contradictory goals simultaneously—expediting the delivery process while spending more time to make sure code is secure and free of bugs.

    To implement DevSecOps without compromising product quality, organizations need to create a culture that deals with security-as-code, encouraging developers to consider the security aspects of their projects and automate security tasks. Organizations need to establish ongoing communication and collaboration between IT engineers, software developers and security teams.

    How DevSecOps Processes Are Transforming the SOC

    Traditionally, SOC processes were completely isolated from the rest of the organization. Developers would build systems, IT Ops run systems, and security protected them. Today, it is understood that merging these three functions into one organization that shares responsibility for security improves security and significantly increases operational efficiency.

    SecOps was a second phase, in which operations and security teams became one organization. Security was shifted left, starting from early stages of IT requirements and system design, not at the end of the process.

    SecOps had a major impact on organizations implementing DevOps. It paved the way for the third phase—broader collaboration between security, operations, and software development teams, known as DevSecOps. This moves security even further to the left, building security into the system from the first iteration of development.

    DevSecOps can operate in parallel to a SOC. Here are some ways SOCs can modernize their processes, even if the SOC itself is a silo:

    • Develop a decentralized SOC with DevOps members: Department members familiar with DevOps can help with incident response by gaining insight into IT systems and understanding vulnerabilities and threats to security personnel.
    • Collaborate with threat hunters and DevOps teams: Instead of isolating threats and reporting them to management, threat hunters can communicate directly with development or operations teams to address key security vulnerabilities.
    • Create a Center of Excellence: SOCs can work with development and operations teams to adopt security best practices and spread these positive results throughout the organization to promote DevSecOps practices.
    • Allow the SOC to provide advice and guidance: Everyone involved in security should have easy access to the SOC and be able to work with the organization’s top security experts.

    Conclusion

    In conclusion, while DevSecOps can significantly impact how SOCs operate, it is unlikely to completely replace the SOC. DevSecOps emphasizes the integration of security practices and tools into the development process from the beginning, which can help to prevent security incidents from occurring in the first place. However, it is still important for organizations to have a dedicated team in place to monitor for and respond to potential security incidents.

    The SOC will continue to play a critical role in protecting an organization’s assets from cybersecurity threats and ensuring the security and integrity of its networks and systems. By adopting DevSecOps practices, the SOC can improve the security and quality of the organization’s software applications, reduce the risk of security incidents and improve the efficiency of its operations. However, the SOC will remain a vital part of the organization’s overall security posture and will continue to evolve and adapt to new challenges as they arise.

  • Software Supply Chain Attacks: How to Disrupt Attackers

    Software Supply Chain Attacks: How to Disrupt Attackers

    Supply chain attacks—compromising an organization via insecure components in its software supply chain—are a growing concern for organizations. Throughout the past three years, an increasing number of open source software package repositories have been found to contain malware, making it clear that all installation and update pathways for software and library code must have security controls applied to prevent and mitigate supply chain attacks.

    Growing Risks of Open Source Software to the Business

    Digital transformation has made every company a software company. As a result, open source software has grown 75% over the past two years. Despite this growth, few companies accurately track the components used in their code. Most lack the policies, processes and tools to keep up with the choices made by their developers, which introduces risk. In fact, 60% of the codebases audited in 2018 contained at least one vulnerability.

    Bad actors have turned to exploiting these weaknesses to compromise organizations. If production code is infected with malware or vulnerabilities, inadvertently sourced from the repository, it may contaminate all organizations that come in contact with it—whether by using the code already in their SDLC or by launching presumed trusted applications from third parties who failed to validate their own code.

    Attackers are also shifting their techniques to mask malware among large packaged objects using obscure formats we refer to as destructive objects. They infiltrate at various points in the development processes opportunistically, knowing they can infiltrate systems outside a managed operational environment. They take advantage of third-party dependencies and use payloads that can sit and wait until an unsuspecting developer implements their software. Hence, software supply chain attacks are difficult to detect, and often achieve dwell-time of hundreds of days.

    Assessing Supply Chain Surface and Sources

    In order to assess weaknesses and identify what warrants continuous monitoring, we need to understand both the surface and sources. 

    When evaluating surface risks, consider the following questions regarding the development environment:

    What technologies, repositories and packages are in use?

    • Inventory technologies used in development: Python, Ruby, JavaScript, Node.js, .NET, etc. This can also refer to operating systems. 
    • Third-party repositories of code: PyPI, RubyGems, NPM, NuGet, PEAR or PECL, and OS repositories such as DebianRepository, CentOS, Ubuntu, AUR and more.
    • Packages: There can be multiple packages from a single repository. How often are packages updated? How often are new packages added?

    Are there update procedures in place?

    • What are the dependencies for every package? How many other packages are pulled from a single package update, and how often are they updated and/or reviewed?

    Who’s managing the verification processes across all these dependencies? What update procedures are in place if there is a personnel change?

    Once these questions have been answered, they should be addressed regularly. The process must be iterative to be successful. 

    When considering attack sources, it’s important to understand the characteristics of repositories teams draw from in order to understand potential areas of weakness. Third-party repositories rarely infect a big project as they are typically found elsewhere (e.g. GitHub) and have thorough code reviews. Official repositories, unofficial mirrors and internal code repositories represent increasing risk potential.

    Random malicious packages, typosquatting, bad code review and phishing developer credentials to hijack accounts are all less technical ploys used by attackers, but equally dangerous. 

    The Software Supply Chain Challenge

    The size, breadth of formats, trusted third-party and open source risks, and misused certificates have made it nearly impossible to stop malware-infected files and objects with today’s signature based, sandbox and vulnerability-based solutions.

    Threats evade dynamic analysis remaining unknown to defenders or lacking details when detected. The explicitness of signature blacklists misses new or never-seen-before code, and sandboxes or dynamic analysis solutions are resource intensive and unable to scale to the breadth and volumes of formats required. Without a way to inspect large or cross platform archives, installers and source code, it’s impossible to extract indicators of compromise. These destructive objects can also impact SOC triage, response and continuous improvement.

    Rising to the Challenge

    How can you address these risks, not only in the software development life cycle (SDLC), but as SOCs address vulnerabilities that may come through other applications and repositories? How do you evaluate and inspect wrappers, digital certificates, executables, scripts, files and libraries, resources, documents and icons?

    It’s vital to establish security practices within SDLC, from training developers on secure coding practices using open source libraries to factoring in detection capabilities including static analysis, dynamic analysis, software composition analysis and manual penetration testing. Implementing a secure SDLC process ensures that the development effort is protected by these activities, augmenting code reviews and infrastructure analysis.

    Teams can extend security controls into the SDLC with technology that provides deep visibility into all aspects of the supply chain, from open source dependencies through continuous integration and delivery of packaged applications. Capabilities that provide greater application security across code development and deployment activities include:

    • File reputation identifies and classifies “known bad” and “known good” files by applying a file’s unique hash against a database of goodware and malware.
    • Automated static analysis detects and classifies unknown malware in code repositories by deobfuscating and decomposing objects and files without executing, and extracting threat indicators. 
    • Dynamic analysis executes files in a safe environment and captures the behaviors and results of malware, allowing the security team to understand what is going to happen.
    • Software composition analysis analyzes applications to detect vulnerabilities, dependencies and licensing requirements in software.
    • Threat intelligence is served up at various stages of the analysis cycle, and represents evidence-based knowledge including context, mechanisms, indicators, implications and action-oriented advice about existing or emerging threats.

    By incorporating these technologies into the SDLC, development teams can obtain continuous validation across the software supply chain. Further automation, implementing new security guidelines and advancing the activities within the existing framework will allow the enterprise to progress its security measures and close gaps in the SDLC and supply chain operations.

    At the same time, it’s important to recognize that threats can still make their way into the software supply chain, and it’s equally important that the SOC remain vigilant about maintaining a clear triage and escalation process. Continuous monitoring of software repositories should be an integral part of good hygiene processes, and incorporated into best practices applied to operational infrastructure, including the SOC. The SOC serves as a centralized management infrastructure to respond, contain and remediate attacks. This includes aggregating and consolidating threat data, building a case for managing a response which can include actions to formulate triage and incident response plans, and moving beyond SIEM.

    — Tomislav Pericin