Celebrate a decade of Kubernetes. Explore why K8s continues to be one of the most prolific open-source systems in the SDLC.
With the guidance of FinOps experts, learn how to optimize AWS containers for performance and cost efficiency.
The topic of security covers many different facets within the SDLC. From focusing on secure application design to designing systems to protect computers, data, and networks against potential attacks, it is clear that security should be top of mind for all developers. This Zone provides the latest information on application vulnerabilities, how to incorporate security earlier in your SDLC practices, data governance, and more.
Full-Stack Security Guide: Best Practices and Challenges of Securing Modern Applications
Building a Semantic Web Search App Using Resource Description Framework and Flask for Cyber Resilience
Data Subject Access Rights (DSAR) In the previous articles (Part 1 and Part 2), we have seen the concept of BigID and how it enhances the data in an organization. In this article, let's see what is Data Subject Access Rights (DSAR) and how they correlate to individual rights in real-time. Data Rights Fulfillment (DRF) is a process of steps/actions taken by an organization with data protection rules and ensuring that individual rights and personal data are respected. What are the most commonly used rights that one individual has the right to ask or know? What level of information does the organization have with regard to data? What are the rights of individuals under the GDPR? Right to data access (Article 15) The right to be informed (Articles 12, 13, and 14) Rights refer to automated individual decision-making, including profiling (Article 22). The right to object (Article 21) The right to data portability (Article 20) The right to restrict processing (Articles 18 and 19) The right to erasure ("right to be forgotten") (Article 17) The right to rectification (Article 16) 1. Right to Data Access This right allows individuals to ask an organization if they have personal data that is concerning them. Individuals are entitled to obtain additional information from the organization regarding the following: For what purposes is the personal data being used or processed? Recipients or services of recipients who have or will receive the data The source of the data, if it was not directly collected from the individual The duration for which the data will be stored or the benchmark used to determine that tenure In summary, the right to access is an important component of data protection regulations, intended to grant individuals greater jurisdiction over their personal data and ensure transparency in how their data is used. 2. The Right to Be Informed This law plays a vital role in an organization and they are responsible for keeping the individuals informed about their data if there are any changes/edits to the data. Transparency is the core principle here for data protection and is key for building trust between organizations and individuals. This is mostly done through a "Privacy Note" or "Non-Disclosure Agreement (NDA)" between both parties. The organization is responsible for making sure these details are written/printed in a very detailed note that individuals can understand easily. Key points that must be included in the Privacy Notice: Identity and contact details of the data Consultant Purpose of data processing Legal basis for processing Recipients or categories of recipients International data transfers Data retention period Individual rights Automated decision-making Source of data (if not collected directly from the individual) 3. Rights Refer to Automated Individual Decision-Making, Including Profiling The individual has specific rights with regard to automated decision-making, including profiling, if the individual feels/suspects the processed data/results were not accurate. These rights are designed to protect individuals from actions that could impact them without any manual intervention. For instance, if a company uses an algorithm to reject job applications based on certain criteria automatically, an individual has the right to: Be informed that their application was rejected through automated decision-making Request human intervention to review the decision Provide additional information that may not have been considered by the automated process They may appeal or raise a flag if they feel the decision was unfair 4. The Right to Object The "right to object" enables individuals to request an organization to stop processing their personal data in some scenarios, like below: Right to object to processing for direct marketing purposes Right to object to processing based on legitimate interests or public task Right to object to processing for research or statistical purposes For instance, if an organization uses personal data to send marketing campaign emails, the individual has the right to object to this kind of processing. Once the individual objects, the company must stop sending these emails to that person immediately. 5. The Right to Data Portability The right to data portability enables individuals to gather and reuse their personal information across multiple services. Organizations need to be able to provide their personal data upon request and in this way it allows them to carry their data in a safe and secure way without compromising their rights. Some of the general examples of how an individual can use these rights are: Switching financial services: An individual might use the right to data portability to transfer their transaction history from one bank to another. Number portability: An individual can use the right to data portability to “port” a mobile number to another mobile network provider. Health services: A patient might transfer their health records from one healthcare provider to another. 6. The Right to Restrict Processing This right provides individuals with the capability to stop processing of their personal data under certain circumstances without necessarily requiring the data to be deleted. An individual has the right to restrict what an organization does with their information, so they can process it as part of an agreement but not send marketing emails. While the processing is restricted by an individual, the organizations can still store their data and the data can be processed with the individual’s consent. An organization must keep track of who has prohibited specific sorts of processing and check that record before processing data. In most circumstances, the best way to address this will be within the software tools that are being used to manage those operations. 7. The Right to Erasure (“Right to Be Forgotten”) This right allows individuals to request that their personal data be deleted when an individual does not want to process their data in an organization. It is a key right of data protection in this digital era, ensuring that individuals have the ability to manage their digital footprint while still protecting their privacy. However, this right is balanced by some exclusions to guarantee that some essential data processing activities can continue where and when needed. For example, a person might request the deletion of their personal data from a company’s database in situations such as when they have withdrawn their consent to receive marketing emails or when they no longer wish to have an account with that company and want all associated data to be erased. By making such a request, the individual ensures that the company stops using their personal data for any purpose, including marketing, account management, or any other processing activity that might have been ongoing. 8. The Right to Rectification It allows individuals to request corrections to their personal data if an individual feels it is inaccurate or incomplete. Organizations need to know everywhere in their organization where data about individuals is stored so they can update those systems if an individual informs them that the data they have is incorrect. If an individual requests an organization to update or edit any of their personal information, they typically need to submit a request to the data controller of the organization that is handling the data. The request should specify what data is incorrect and what the correct information should be. In the future post, we will look at how BigID addresses DSAR and DRF requests and the impact it has on data and individuals. This framework is essential for maintaining justice and accountability in the age of AI. Reference Articles BigID-Automate-Data-Access-Rights-Fulfillment-White-Paper
Editor's Note: The following is an article written for and published in DZone's 2024 Trend Report, Enterprise Security: Reinforcing Enterprise Application Defense. In today's cybersecurity landscape, securing the software supply chain has become increasingly crucial. The rise of complex software ecosystems and third-party dependencies has introduced new vulnerabilities and threats, making it imperative to adopt robust security measures. This article delves into the significance of a software bill of materials (SBOM) and DevSecOps practices for enhancing application security. We will cover key points such as the importance of software supply chain security, the role of SBOMs, the integration of DevSecOps, and practical steps to secure your software supply chain. Understanding the Importance of Software Supply Chain Security Software supply chain security encompasses the protection of all components and processes involved in the creation, deployment, and maintenance of software. This includes source code, libraries, development tools, and third-party services. As software systems grow more interconnected, the attack surface expands, making supply chain security a critical focus area. The software supply chain is vulnerable to various threats, including: Malicious code injection – attackers embedding malicious code into software components Dependency hijacking – compromising third-party libraries and dependencies Code tampering – making unauthorized modifications to source code Credential theft – stealing credentials to access and manipulate development environments To combat these threats, a comprehensive approach to software supply chain security entails: Continuous monitoring and assessment – regularly evaluating the security posture of all supply chain components Collaboration and transparency – fostering open communication between developers, security teams, and third-party vendors Proactive threat management – identifying and mitigating potential threats before they can cause damage The Importance of an SBOM and Why It Matters for Supply Chain Security An SBOM is a detailed inventory of all components, dependencies, and libraries used in a software application. It provides visibility into the software's composition, enabling organizations to: Identify vulnerabilities – By knowing exactly what components are in use, security teams can swiftly identify which parts of the software are affected by newly discovered vulnerabilities, significantly reducing the time required for remediation and mitigating potential risks. Ensure compliance – Many regulations mandate transparency in software components to ensure security and integrity. An SBOM helps organizations adhere to these regulations by providing a clear record of all software components, demonstrating compliance, and avoiding potential legal and financial repercussions. Improve transparency – An SBOM allows all stakeholders, including developers, security teams, and customers, to understand the software’s composition. This transparency fosters better communication, facilitates informed decision making, and builds confidence in the security and reliability of the software. Enhance supply chain security – Detailed insights into the software supply chain help organizations manage third-party risks more effectively. Having an SBOM allows for better assessment and monitoring of third-party components, reducing the likelihood of supply chain attacks and ensuring that all components meet security and quality standards. Table 1. SBOM benefits and challenges Benefits Challenges Enhanced visibility of all software components Creating and maintaining an accurate SBOM Faster vulnerability identification and remediation Integrating SBOM practices into existing workflows Improved compliance with regulatory standards Ensuring SBOM data accuracy and reliability across the entire software development lifecycle (SDLC) Regulatory and Compliance Aspects Related to SBOMs Regulatory bodies increasingly mandate the use of SBOMs to ensure software transparency and security. Compliance with standards such as the Cybersecurity Maturity Model Certification (CMMC) and Executive Order 14028 on "Improving the Nation's Cybersecurity" emphasizes the need for comprehensive SBOM practices to ensure detailed visibility and accountability for software components. This enhances security by quickly identifying and mitigating vulnerabilities while ensuring compliance with regulatory requirements and maintaining supply chain integrity. SBOMs also facilitate rapid response to newly discovered threats, reducing the risk of malicious code introduction. Creating and Managing SBOMs An SBOM involves generating a detailed inventory of all software components, dependencies, and libraries and maintaining it accurately throughout the SDLC to ensure security and compliance. General steps to create an SBOM include: Identify components – list all software components, including libraries, dependencies, and tools Document metadata – record version information, licenses, and source details for each component Automate SBOM generation – use automated tools to generate and update SBOMs Regular updates – continuously update the SBOM to reflect changes in the software Several tools and technologies aid in managing SBOMs, such as: CycloneDX, a standard format for creating SBOMs OWASP dependency-check identifies known vulnerabilities in project dependencies Syft generates SBOMs for container images and filesystems Best Practices for Maintaining and Updating SBOMs Maintaining and updating an SBOM is crucial for ensuring the security and integrity of software applications. Let's review some best practices to follow. Automate Updates Automating the update process of SBOMs is essential to keeping them current and accurate. Automated tools can continuously monitor software components and dependencies, identifying any changes or updates needed to the SBOM. This practice reduces the risk of human error and ensures that the SBOM reflects the latest state of the software, which is critical for vulnerability management and compliance. Implementation tips: Use automation tools like CycloneDX and Syft that integrate seamlessly with your existing development environment Schedule regular automated scans to detect updates or changes in software components Ensure that the automation process includes notification mechanisms to alert relevant teams of any significant changes Practices to avoid: Relying solely on manual updates, which can lead to outdated and inaccurate SBOMs Overlooking the importance of tool configuration and updates to adapt to new security threats Integrate Into CI/CD Embedding SBOM generation into the continuous integration and continuous deployment (CI/CD) pipeline ensures that SBOMs are generated and updated automatically as part of the SDLC. This integration ensures that every software build includes an up-to-date SBOM, enabling developers to identify and address vulnerabilities early in the process. Implementation tips: Define clear triggers within the CI/CD pipeline to generate or update SBOMs at specific stages, such as code commits or builds Use tools like Jenkins and GitLab CI that support SBOM generation and integrate with popular CI/CD platforms Train development teams on the importance of SBOMs and how to use them effectively within the CI/CD process Practices to avoid: Neglecting the integration of SBOM generation into the CI/CD pipeline, which can lead to delays and missed vulnerabilities Failing to align SBOM practices with overall development workflows and objectives Regular Audits Conducting periodic audits of SBOMs is vital to verifying their accuracy and completeness. Regular audits help identify discrepancies or outdated information and ensure that the SBOM accurately reflects the software's current state. These audits should be scheduled based on the complexity and frequency of software updates. Implementation tips: Establish a routine audit schedule, such as monthly or quarterly, depending on the project’s needs Involve security experts in the auditing process to identify potential vulnerabilities and ensure compliance Use audit findings to refine and improve SBOM management practices Practices to avoid: Skipping audits, which can lead to undetected security risks and compliance issues Conducting audits without a structured plan or framework, resulting in incomplete or ineffective assessments DevSecOps and Its Role in Software Supply Chain Security DevSecOps integrates security practices into the DevOps pipeline, ensuring that security is a shared responsibility throughout the SDLC. This approach enhances supply chain security by embedding security checks and processes into every stage of development. Key Principles and Practices of DevSecOps The implementation of key DevSecOps principles can bring several benefits and challenges to organizations adopting the practice. Table 3. DevSecOps benefits and challenges Benefits Challenges Identifies and addresses security issues early in the development process Requires a shift in mindset toward prioritizing security Streamlines security processes, reducing delays and improving efficiency Integrating security tools into existing pipelines can be complex Promotes a culture of shared responsibility for security Ensuring SBOM data accuracy and reliability Automation Automation in DevSecOps involves integrating security tests and vulnerability scans into the development pipeline. By automating these processes, organizations can ensure consistent and efficient security checks, reducing human error and increasing the speed of detection and remediation of vulnerabilities. This is particularly important in software supply chain security, where timely identification of issues can prevent vulnerabilities from being propagated through dependencies. Implementation tip: Use tools like Jenkins to automate security testing within your CI/CD pipeline. Collaboration Collaboration between development, security, and operations teams is essential in DevSecOps. This principle emphasizes breaking down silos and fostering open communication and cooperation among all stakeholders. Effective collaboration ensures that security considerations are integrated from the start, leading to more secure software development processes. Implementation tip: Establish regular cross-team meetings and use collaboration tools to facilitate communication and knowledge sharing. Continuous Improvement Continuous improvement in DevSecOps involves regularly updating security practices based on feedback, new threats, and evolving technologies. This principle ensures that security measures remain effective and relevant so that they adapt to changes in the threat landscape and technological advancements. Implementation tip: Use metrics and key performance indicators (KPIs) to evaluate the effectiveness of security practices and identify areas for improvement. Shift-Left Security Shift-left security involves integrating security early in the development process rather than addressing it at the end. This approach allows developers to identify and resolve security issues during the initial stages of development, reducing the cost and complexity of fixing vulnerabilities later. Implementation tip: Conduct security training for developers and incorporate security testing tools into the development environment. Application Security Testing in DevSecOps Application security testing is crucial in DevSecOps to ensure that vulnerabilities are detected and addressed early. It enhances the overall security of applications by continuously monitoring and testing for potential threats. The following are different security testing methods that can be implemented: Static application security testing (SAST) analyzes source code for vulnerabilities. Dynamic application security testing (DAST) tests running applications for security issues. Interactive application security testing (IAST) combines elements of SAST and DAST for comprehensive testing. Open-source tools and frameworks that facilitate application security testing include: SonarQube, a static code analysis tool OWASP ZAP, a dynamic application security testing tool Grype, a vulnerability scanner for container images and filesystems Integrating Security Into CI/CD Pipelines Integrating security into CI/CD pipelines is essential to ensure that security checks are consistently applied throughout the SDLC. By embedding security practices into the CI/CD workflow, teams can detect and address vulnerabilities early, enhancing the overall security posture of the application. Here are the key steps to achieve this: Incorporate security tests into CI/CD workflows Use automated tools to scan for vulnerabilities during builds Continuously monitor for security issues and respond promptly Automating Security Checks and Vulnerability Scanning Automation ensures that security practices are applied uniformly, reducing the risk of human error and oversight to critical security vulnerabilities. Automated security checks can quickly identify vulnerabilities, allowing for faster remediation and reducing the window of opportunity for attackers to exploit weaknesses. DevSecOps emphasizes the importance of building security into every stage of development, automating it wherever possible, rather than treating it as an afterthought. Open-source CI/CD tools like Jenkins, GitLab CI, and CircleCI can integrate security tests into the pipeline. While automation offers significant benefits, there are scenarios where it may not be appropriate, such as: Highly specialized security assessments Context-sensitive analysis Initial setup and configuration False positives and negatives Ensuring Continuous Security Throughout the SDLC Implement continuous security practices to maintain a strong security posture throughout the SDLC and regularly update security policies, tools, and practices to adapt to evolving threats. This proactive approach not only helps in detecting and mitigating vulnerabilities early but also ensures that security is integrated into every phase of development, from design to deployment. By fostering a culture of continuous security improvement, organizations can better protect their software assets and reduce the likelihood of breaches. Practical Steps to Secure Your Software Supply Chain Implementing robust security measures in your software supply chain is essential for protecting against vulnerabilities and ensuring the integrity of your software. Here are practical steps to achieve this: Establishing a security-first culture: ☑ Implement training and awareness programs for developers and stakeholders ☑ Encourage collaboration between security and development teams ☑ Ensure leadership supports a security-first mindset Implementing access controls and identity management: ☑ Implement least privilege access controls to minimize potential attack vectors ☑ Secure identities and manage permissions using best practices for identity management Auditing and monitoring the supply chain: ☑ Continuously audit and monitor the supply chain ☑ Utilize open-source tools and techniques for monitoring ☑ Establish processes for responding to detected vulnerabilities Key Considerations for Successful Implementation To successfully implement security practices within an organization, it's crucial to consider both scalability and flexibility as well as the effectiveness of the measures employed. These considerations ensure that security practices can grow with the organization and remain effective against evolving threats. Ensuring scalability and flexibility: ☑ Design security practices that can scale with your organization ☑ Adapt to changing threat landscapes and technological advancements using flexible tools and frameworks that support diverse environments Measuring effectiveness: ☑ Evaluate the effectiveness of security efforts using key metrics and KPIs ☑ Regularly review and assess security practices ☑ Use feedback to continuously improve security measures Conclusion Securing the software supply chain is crucial in today's interconnected world. By adopting SBOM and DevSecOps practices using open-source tools, organizations can enhance their application security and mitigate risks. Implementing these strategies requires a comprehensive approach, continuous improvement, and a security-first culture. For further learning and implementation, explore the resources below and stay up to date with the latest developments in cybersecurity. Additional resources: "Modern DevSecOps: Benefits, Challenges, and Integrations To Achieve DevSecOps Excellence" by Akanksha Pathak "Building Resilient Cybersecurity Into Supply Chain Operations: A Technical Approach" by Akanksha Pathak "Demystifying SAST, DAST, IAST, and RASP: A Comparative Guide" by Apostolos Giannakidis Software Supply Chain Security: Core Practices to Secure the SDLC and Manage Risk by Justin Albano, DZone Refcard Getting Started With CI/CD Pipeline Security by Sudip Sengupta and Collin Chau, DZone Refcard Getting Started With DevSecOps by Caroline Wong, DZone Refcard This is an excerpt from DZone's 2024 Trend Report,Enterprise Security: Reinforcing Enterprise Application Defense.Read the Free Report
When it comes to secure web applications, we must keep sensitive data secure during the communication period. Sadly, while HTTPS encrypts data as it moves from point A to point B, the information is still exposed in a browser's network tab and can leak out this way. In this post, I will give you an example of implementing end-to-end encryption of API calls in your secure web app built with Angular. Encryption Workflow Weak protections have traditionally been obfuscation with Base64 encoding or custom schemes. Public key cryptography (PKC) is considered a modern solution to be more secure. It uses a key pair one public key for encryption, and the other private key for decryption. A public key is distributed and a private key is kept on the server. The encryption workflow is as follows: Client-side encryption: Your Angular application encrypts the data with the server’s public key before transmitting it to the API. Secure transmission: Over an HTTPS connection, the network then transmits the encrypted data. Server-side decryption: The server decrypts the data by missioning its private key because it receives the encrypted data, seeing the original information. Server-side encryption (Optional): Before sending the response back to the client, the server can also encrypt the data for additional security. Client-side decryption: Finally, the client decrypts the encrypted response from the server using a public key stored in the web application. Implementation Into Angular App Here is a detailed strategy to implement end-to-end encryption in your Angular financial app. 1. Library Selection and Installation Choose a well-maintained library like Angular CryptoJS or Sodium for JavaScript, but still put more reliance than loafing in trying to implement them. These libraries contain the APIs for encryption and decryption which is provided by multiple algorithms. PowerShell npm install crypto-js 2. Key Management Implement a feature to keep the server's public key safe. There are a couple of common approaches to this: Server-side storage: One relatively simple solution is to store the public key on your backend server, and then retrieve it during application initialization in Angular via an HTTPS request. Key Management Service (Optional): For more advanced set ups, consider a KMS dedicated to secret management, but this requires an extra layer. 3. Create Client-Side Encryption and Decryption Service Create a common crypto service to handle the application data encryption and decryption. TypeScript // src/app/services/appcrypto.service.ts import { Injectable } from '@angular/core'; import * as CryptoJS from 'crypto-js'; @Injectable({ providedIn: 'root' }) export class AppCryptoService { private appSerSecretKey: string = 'server-public-key'; encrypt(data: any): string { return CryptoJS.AES.encrypt(JSON.stringify(data), this.appSerSecretKey).toString(); } decrypt(data: string): any { const bytes = CryptoJS.AES.decrypt(data, this.appSerSecretKey); return JSON.parse(bytes.toString(CryptoJS.enc.Utf8)); } } 4. Application API Call Service Create a common service to handle the web application's common HTTP methods. TypeScript // src/app/services/appcommon.service.ts import { Injectable, Inject } from '@angular/core'; import { Observable } from 'rxjs'; import { map } from 'rxjs/operators'; import { HttpClient, HttpHeaders } from '@angular/common/http'; import { AppCryptoService } from '../services/crypto.service'; @Injectable({ providedIn: 'root' }) export class AppCommonService { constructor(private appCryptoService: AppCryptoService private httpClient: HttpClient) {} postData(url: string, data: any): Observable<any> { const encryptedData = this.appCryptoService.encrypt(data); return this.httpClient.post(url, encryptedData); } } 5. Server-Side Decryption On the server side, you have to decrypt all incoming request payloads and encrypt response payloads. Here's an example using Node. js and Express: JavaScript // server.js const express = require('express'); const bodyParser = require('body-parser'); const crypto = require('crypto-js'); const app = express(); const secretKey = 'app-secret-key'; app.use(bodyParser.json()); // Using middleware to decrypt the incoming request bodies app.use((req, res, next) => { if (req.body && typeof req.body === 'string') { const bytes = crypto.AES.decrypt(req.body, secretKey); req.body = JSON.parse(bytes.toString(crypto.enc.Utf8)); } next(); }); // Test post route call app.post('/api/data', (req, res) => { console.log('Decrypted data:', req.body); // response object const responseObj = { message: 'Successfully received' }; // Encrypt the response body (Optional) const encryptedResBody = crypto.AES.encrypt(JSON.stringify(responseBody), secretKey).toString(); res.send(encryptedResBody); }); const PORT = process.env.PORT || 3000; app.listen(PORT, () => { console.log(`Server running on port ${PORT}`); }); 6. Server-Side Encryption (Optional) The response of the server can also be sent back to the client in an encrypted form for security. This does add a layer of security, though with the caveat that it may impact system performance. 7. Client-Side Decryption (Optional) When the response is encrypted from the server, decrypt it on the client side. Conclusion This example keeps it simple by using AES encryption. You may want additional encryption mechanisms, depending on your security needs. Don't forget to manage errors and exceptions properly. This is a somewhat crude implementation of encryption in your Angular web app when making API calls around.
By now we've all heard about — or been affected by — the CrowdStrike fiasco. If you haven't, here's a quick recap. An update to the CrowdStrike Falcon platform, pushed on a Friday afternoon, caused computers to crash and be unbootable. The update was pushed to all customers at once, and the only way to recover was to boot into "Safe Mode" and uninstall the update. That often required direct physical access to the affected computer, making recovery times even longer. I'm not going to go into a detailed post-mortem of all that went wrong, because I honestly don't know the gory details (Was it dereferencing a null pointer? Was it an attempt to read a protected memory location?). There have been a number of posts and articles written about the incident, and I'm sure that CrowdStrike is doing a deep dive into what went wrong and how to prevent it from happening again. (Plus there's that $10 UberEats gift card!) This is absolutely not a finger-pointing exercise. I'm not here to say "I told you so" or "You should have done it this way." There's plenty of blame to go around in any large-scale incident like this. but examining how we could have avoided such an incident, from an architectural perspective and how to make sure it doesn't repeat, is a valuable exercise. Issues Here are the issues I have with how this was rolled out: The update was pushed to all customers at once. This is a recipe for disaster. Updates should be pushed in a phased manner, starting with a small subset of customers, and then increasing the number of customers as the update is proven to be stable. There are, of course, situations where this is just not possible. Zero-day exploits need to be patched immediately, and there is no time for a phased rollout. The updates were run as "mandatory" and "background" updates. This means that the updates were pushed to the computers without the user's knowledge or consent. In general, System Admins should have a warning before such updates are applied and should have the ability to forgo the updates if they choose. The update was pushed on a Friday afternoon. This is a classic "bad idea" in the world of IT. Updates should be pushed during the week when there are more people available to deal with any issues that arise. (Let's not get into this argument, shall we? There are lots of opinions on this, and I'm sure that you have yours.) Again, there are always situations where an emergency update is required, and there is no time for a phased rollout. There was no fall-back strategy in place for if the update went wrong. The main thing missing from the entire episode was any idea of resiliency. How do you recover from a failed update? How do you ensure that your customers are not left high and dry when an update goes wrong? How do you ensure that your customers are not left with a bricked computer? These are all questions of resiliency that should be explicitly addressed in any update strategy. How the Embedded World Handles Updates In the embedded world, we have been designing systems to handle firmware updates — and update failures — for decades. Back in my days, we had a firmware update architecture that would update the firmware on the device, and if the update failed, the device would automatically roll back to the previous version. This was a system that was designed to be updated over the air (OTA) and to be updated in the field. We had to design for the worst-case scenario that was both robust and recoverable. How did we do this? We implemented what is known as A/B partitioning. The device has 2 partitions (well, more really, but we'll cover that in a minute), A and B. When an update is pushed, it is pushed to the partition that is not currently running the active system. The device then reboots into the new partition, and if the update is successful, the device continues to run normally. If the update fails, the device reboots into the previous partition, and the device is back up and running. The failed partition can then be updated again, and the process repeated until the update is successful. It is a fail-safe way to push updates to devices that are in the field, and it is a system that has been in use for decades in the embedded world. If you have an Android-based phone, chances are that your phone is using this system to update the OS. If you have a Mac, you may notice that you have a small disk partition that can be used for "recovery" in case of a system failure. It's not a full A/B partitioning system, but it is a similar idea. Why Didn't CrowdStrike Use This System? Well, the first problem is that these systems were all running Windows. I'll defer the whole "don't run production systems on Windows" argument for another time, but suffice it to say that Windows is not known for its robustness in the face of updates. Windows updates have been known to cause all sorts of problems, from the benign to the catastrophic. Anyone that runs Windows daily can attest to these problems. Drivers conflict, updates fail, and the system is left in a state that is not recoverable. The dreaded Blue Screen of Death (BSOD). Windows is also not built to use such an A/B partitioning system. Windows is designed to be updated in place, by the user, and the user is expected to be able to recover from a failed update. Much of this has been taken over by remote administration, but the basic idea is still the same: Windows is designed to be updated in place. Recent versions of Windows do have a system of "snapshots" of prior working versions that can be rolled back to, but this is not the same as a full A/B partitioning system and the roll-back is not automatic. The CrowdStrike update pushed a change to a driver that is loaded early in the boot phase. When this driver (or any driver that is loaded into kernel space) fails for any reason, Windows will refuse to boot and go to the Blue Screen of Death (BSOD). This is how Windows protects itself from malicious drivers and driver conflicts. Effective, sure, but not the most resilient way to go when you're dealing with large production systems that *must* be up and running all the time. Production servers simply must be available all the time. There is no room for downtime, and there is no room for failure. This is why we have resiliency built into our systems. This is why we have A/B partitioning. How Does A/B Partitioning Actually Work? A/B partitioning schemes are designed to provide high resiliency in systems that must be up and running all the time, or where a failed update can be extremely difficult or costly to recover. Think about a small sensor embedded in a hydroelectric dam that needs to get a firmware update over the air. Now think about what happens if that update fails for some reason. Having that sensor offline due to a failed update can have catastrophic results. Sending a technician out to that remote place, to crawl into some small, dark, possibly unsafe place to fix it just isn't a viable solution. Having a system that allows for the graceful recovery of the device is the only practical solution. This is a simple diagram of how A/B partitioning works. The system boots into partition A, and when an update is pushed, it is written to partition B. The system then reboots from partition B, and if the update is successful, the system continues to run the updated firmware. If the update fails, the system reboots from partition A, and the system is back up and running. The failed partition can then be updated again, and the process repeated. Once successful, the system will be running out of partition B, and partition A will be the new 'spare'. During the next update cycle, the system will update the partition that is not currently running (in this example, partition A). This way, the system is always running on a known-good partition, and the system can always recover from a failed update. This makes the system extremely resilient in the face of failed updates. Resiliency. It's a good thing. Is there a cost for this? Of course. There is a cost in terms of storage space, obviously. You need to have enough space to hold 2 copies of the OS, and that can be expensive. But you don't have to have double the storage space of the entire system, as only the critical OS components need to be stored in the A/B partitions. All of the user and application data can be stored in a separate partition that is always available to the running OS no matter which partition it is running from. Is storage expensive? It can be, yes, but let's compare the relatively minor cost of this extra bit of storage to, say, the $500 million dollars that Delta Airlines has reportedly lost over the latest incident. Seems like a small price to pay for the added resiliency that it could provide. Conclusion The CrowdStrike meltdown was a failure of epic proportions, that much is clear. But there are a lot of factors that could have prevented it. Once the update escaped the validation and Q/A phase at CrowdStrike (which they acknowledge it shouldn't have), the lack of resiliency in the update process was the main issue and one that could have been addressed with an A/B partitioning scheme. A/B partitioning isn't available on Windows machines, but it is absolutely available for other architectures. (I know I said I wouldn't get into the "don't run your production systems on Windows" argument, but I just can't help myself.) All drivers for Microsoft Windows must be cryptographically signed. Most software for Windows is also required to be signed. The same is true for macOS. All system and driver updates — really anything that runs in any privileged mode — should be cryptographically signed and verified before being allowed to be installed and run. Bootware ensures that all updates are cryptographically signed and verified before being allowed to be installed and run. This is a critical part of the security and resiliency of the system. How a truly secure and resilient update process should be rolled out: Updates should be pushed in a phased manner, starting with a small subset of customers, and then increasing the number of customers as the update is proven to be stable whenever possible. Non-phased rollouts should be reserved for true emergency situation like zero-day exploits. Updates should be pushed during the week when there are more people available to deal with any issues that arise. Again, there are always situations where an emergency update is required, and there is no time for a phased rollout. Administrators should be informed before an update is rolled out and should have the ability to forgo the update if they choose. There should be a fall-back and recovery strategy in place for when an update goes wrong. This is how a truly secure and resilient update process should be rolled out.
One-time passwords are one of the most relied-on forms of multi-factor authentication (MFA). They’re also failing miserably at keeping simple attacks at bay. Any shared secret a user can unknowingly hand over is a target for cybercriminals, even short-lived TOTPs. Consider this: What if the multi-factor authentication your users rely on couldn’t save your organization from a large-scale account takeover? That’s what happened to an organization using SMS one-time passwords to secure customer accounts. We’ll call the affected organization “Example Company,” or EC for short. By deploying a replica of the real EC login page and a “spoofed” URL — a similar-looking (but fake) web address — threat actors intercepted user credentials and OTPs in real-time. This allowed them to authenticate on the legitimate site, granting full account access and potentially persistent tokens or cookies via the “remember me” function. Figure 1: SMS MFA bypass attack using MITM tactics This is not an isolated incident. Numerous high-profile breaches highlight the glaring insufficiency of traditional MFA implementations. Don’t get the wrong idea, though: two factors are still better than one. As Slavik Markovich asserts in SC Magazine, “MFA implementation remains an essential pillar in identity security.” He further points out that “when properly configured, MFA blocks 99% of attacks.” Snowflake, a cloud data provider serving large enterprises like AT&T, is still reeling from a breach involving user credentials — reportedly without MFA in place. AT&T paid a whopping 5.7 Bitcoin ($370,000 USD at the time of payment) ransom to the cybercriminals responsible, a deal struck for deleting the stolen data. Could MFA have saved the telecom company over a quarter million? It would have certainly made it much harder to abscond with 109 million customers’ call and text messaging metadata. Yet, despite the effectiveness of MFA, adoption lags. A recent Wall Street Journal article highlights this gap, quoting Keeper Security CTO Craig Lurey: “MFA isn’t always easy. Older technology might not be able to run the software necessary for MFA.” Users, too, are to blame, Lurey told the Journal, noting they “push back against MFA as cumbersome.” With MFA adoption meeting such resistance, it’s a tough pill to swallow when some implementations are still phishable and vulnerable to attack. To better defend against attacks that can defeat vulnerable MFA implementations, we need to understand how these tactics tick. The Anatomy of an SMS MFA Bypass Attack The threat actor that targeted EC, the company in my initial example, didn’t use sophisticated methods to overwhelm network infrastructure or exploit a backdoor. They went after unsuspecting users, tricking them into handing over credentials on an impostor login page. After plying the real site for an MFA challenge sent to users’ phones, it was a simple matter of collecting SMS OTPs and logging in. This method, known as a man-in-the-middle (MITM) attack, is increasingly common. While some MFA bypass tactics like prompt bombing and basic social engineering rely on the naivety of users, a pixel-perfect MITM attempt can be much more convincing — yet still deviously simple. The attacker doesn’t need to hijack a session, steal cookies, or swap a SIM card. Here’s a breakdown of a typical MITM attack: The threat actor creates (or purchases a kit containing) a convincing imitation of a genuine login page, often using a domain name that looks similar to the real one. Users are lured to this site, usually through phishing emails or malicious ads. When a user enters their credentials, the attacker captures them. If MFA is required, the legitimate site sends a one-time code to the user. The user, still connected to the fake site, enters this code, which the cybercriminal then uses to log in on the real site. The genius of MITM attacks, and their danger, is simplicity. The fraudster doesn’t need to hijack a session, steal cookies, or swap a SIM card. It doesn’t require breaking encryption or brute-forcing passwords. Instead, it leverages human behavior and the limitations of certain MFA methods, particularly those relying on one-time passwords with a longer lifespan. But what makes this tactic particularly insidious is that it can bypass MFA in real-time. The user thinks they’re going through a normal, secure login process, complete with the anticipated MFA step. In reality, they’re handing over their account to a cybercriminal. Simple MITM attacks are significantly easier to pull off for novice attackers compared to increasingly popular AITM (adversary-in-the-middle) variants, which typically require an indirect or reverse proxy to collect session tokens. However, with AITM kits readily available from open-source projects like EvilProxy and the PhaaS (phishing-as-a-service) package from Storm-1011, more complex approaches are available to script kiddies willing to learn basic functions. Not All MFA Is Created Equally MFA might have prevented or contained the Snowflake breach, but it also might have been a story like TTS, the travel platform. The harsh reality is that not all MFA is created equally. Some current popular methods, like SMS OTPs, are simply not strong enough to defend against increasingly advanced and persistent threats. The root of the problem lies with the authentication factors themselves. Knowledge-based factors like passwords and OTPs are inherently vulnerable to social engineering. Even inherence factors can be spoofed, hijacked, or bypassed without proper safeguards. Only possession factors, when properly implemented using public key cryptography (as with FIDO2/U2F or passkeys), offer sufficient protection against MFA bypass attacks. Case in point: TTS, our travel platform example, used SMS OTPs. It’s technically MFA, but it’s a weak variant. It’s high time we faced the fact that SMS was never intended to be used as a security mechanism, and text messages are always out-of-band. Apart from the direct threat of SIM swaps, SMS OTPs time out more slowly than their TOTP authenticator app counterparts, which makes them magnets for phishing. The same weaknesses are present in email and authenticator app OTPs. Anything a user can see and share with a cybercriminal, assume it will be a target. Magic links could have helped in both breaches we discussed because they are links that don’t require manual input. An attacker positioned as a man in the middle wouldn’t be able to intercept a magic link. Instead, they’d be forced to breach the target user’s email account. This underscores a painfully obvious issue at the core of our MFA landscape: shared, transferable secrets. Whether it’s an SMS, email, or even time-based OTP from an authenticator app, these methods all rely on a piece of information that can be knowingly (or unknowingly) shared by the user. Same-device authentication is the only way to increase the certainty you’re dealing with the person who initiated the MFA challenge. The Key to Secure MFA Is in Your User’s Device Possession-based authentication offers a promising solution to the problems posed by out-of-band MFA. With device-enabled auth methods creating reliable, secure ecosystems, the “what you have” factor is open to anyone with a capable smartphone or browser. In today’s threat landscape, the key to stopping MFA bypass attacks is in your user’s device. Here’s why: No shared, transferable secrets: Unlike OTPs, there’s no code for users to manually enter or click. The authentication process happens through device-bound properties that can’t be intercepted or duplicated. Genuine same-device authentication: Biometrics or a PIN can prove presence, but more significantly, they ensure it’s all happening on the same device. Phishing resistance: Since there’s no secret for unsuspecting users to enter spoofed URLs, phishing attempts become largely pointless. A fake login page can’t steal a user’s smartphone. Smoother UX: Users don’t need to wait for (or miss) SMSes, emails, or copy codes from an app. A simple PIN or biometric verification is all it takes. Reduced reliance on out-of-band ecosystems: SMS, email, and authenticator app OTPs may be convenient, but they’re a nightmare when a threat actor gets through. Admittedly, there are some adoption hurdles that we need to face. Transitioning to these newer, more secure MFA methods can pose financial challenges when organizations update their infrastructure. It can cause uncertainty among uninformed users who view biometric authentication with skepticism (which is often misplaced when it comes to FIDO authentication). However, moving to device-based MFA is a necessary, essential step for companies with vulnerable user populations still using OTPs for MFA. For organizations serious about security, it’s not worth waiting for an expensive MFA bypass attack. The cost of a modern solution is fractional when compared to the reputation loss and financial burden of a breach. Despite the minor roadblocks to adoption, it’s up to security leaders to lead the charge toward safer, possession-based MFA — and far, far away from shared secrets.
AI vulnerabilities: From medical diagnostics to autonomous vehicles, discover how changing a single pixel can compromise advanced deep learning models and explore the critical challenges to securing our AI-powered future. Introduction Deep learning (DL) is a fundamental component of Artificial Intelligence (AI). It aims to enable machines to perform tasks that require decision-making mechanisms that tend to approximate those of human reasoning. DL models are at the heart of many advanced applications, such as medical diagnostics and autonomous vehicle driving. Unfortunately, like all other systems, they are not immune to vulnerabilities that can be exploited by cybercriminals. The one-pixel attack, for example, is one of the most effective methods of disrupting the accuracy of a model by modifying, as its name suggests, just one pixel of an image. This article explains how one-pixel attacks work, and their possible impact in many fields. It also talks about strategies for protecting against them, to improve the reliability and security of AI systems. Overview Introduction to Deep Learning Deep learning is a subset of AI that involves training neural networks to recognize patterns in data. These neural networks mimic the structure and function of the human brain, enabling them to learn from large amounts of data and produce predictions or make decisions. For example, deep learning models can identify objects in images, understand spoken language (Natural Language Processing/ NLP), and even diagnose diseases from medical images. To fully understand the importance of deep learning technology, here are a few examples of its practical use: 1. Health: Medical Imaging Deep learning models are widely used in the processing and understanding of medical imaging to detect diseases such as cancer. For example, convolutional neural networks (CNN) are being applied to the analysis of mammograms to detect breast cancer. This technology offers highly accurate identification of malignant tumors. It can help reduce the risk of human error by offering radiologists a second opinion. 2. Autonomous Driving Autonomous vehicles rely on DL algorithms to process data from sensors and cameras in real-time. These models are used for object detection, lane recognition, and decision-making. Tesla's Autopilot, for example, uses deep learning to process data and react to the vehicle's environment, ensuring safe navigation and driving. 3. Natural Language Processing DL is an essential component of natural language processing (NLP). Before the advent of generative AI (GenAI), DL enabled advances in conversational technologies such as chatbots and virtual assistants like Google Assistant and Amazon Alexa, for example. These systems use deep learning to understand and process human language so that they can answer queries, perform tasks, and even engage in conversations with users. There are many other examples. In the financial sector, deep learning models are being used to detect fraudulent activity by analyzing transaction patterns and identifying anomalies indicative of fraud. In retail, platforms like Amazon or Netflix are using Deep Learning to offer personalized recommendations. The systems analyze user behavior, preferences, and purchase history in order to improve the user experience and on the other hand to increase sales. All this illustrates the extent of the impact of deep learning in various sectors, and the areas in which this technology is capable of improving the efficiency and accuracy of complex tasks. What Motivates an Attack on Deep Learning? As we have just seen, deep learning models are powerful tools used in a wide range of applications. However, they can be vulnerable to attack. Cybercriminals can target these models to cause them to make incorrect decisions, which can have serious consequences. For example, by manipulating the neural network of an autonomous car, an attacker could cause the car to misinterpret a signal and endanger the vehicle's occupants. Real-Life Example In a real-life scenario, researchers demonstrated the vulnerability of a deep-learning model used to detect breast cancer. By modifying a single pixel in a medical image, they were able to trick the IBM CODAIT MAX breast cancer detector into making a false diagnosis(*). This example highlights the serious implications of such attacks in critical areas such as health. (*) Cf arXiv:2012.00517v6 "One-Pixel Attack Deceives Computer-Assisted Diagnosis of Cancer" "ReFace attacks can successfully deceive commercial face recognition services in a transfer attack setting and reduce face identification accuracy from 82% to 16.4% for AWS SearchFaces API and Azure face verification accuracy from 91% to 50.1%" - arXiv:2012.00517v6 Overview of the One-Pixel Attack The one-pixel attack targets deep learning models by altering a single pixel of an input image, causing the model to misclassify the image. This attack uses the differential evolution algorithm to identify the optimal pixel to modify. This method can be effective even without knowing the internal parameters of the model. Propagation maps show how the modification of a single pixel can affect a deep neural network. These maps show how the change propagates through the layers of the network, and how a small localized change can influence the final decision. That’s why one-pixel attacks present serious risks in many areas. In medical imaging, they can lead to incorrect diagnoses, as in the case of the breast cancer detector. In cybersecurity, they can fool facial recognition systems for example. Mechanism of the One-Pixel Attack As we understand now, a one-pixel attack is a type of adversarial attack that exploits the vulnerability of deep neural networks by modifying a single pixel of an input image in order to cause misclassification. Contradictory Attack An adversarial attack involves making small, intentional changes to input data in order to trick a machine-learning model into making incorrect predictions or decisions. This can happen in many different ways, beyond images. For example, in text data, attackers can change words or characters to trick a linguistic model. In audio data, they can add subtle noise to fool voice recognition systems. In cybersecurity, adversarial attacks may involve slightly modifying the code of malicious software to bypass anti-virus software. Similarly, in financial systems, attackers can manipulate market data to trick trading algorithms into making erroneous trades. One-Pixel Attack One-pixel attacks exploit the complex decision-making processes of deep neural networks. They use the differential evolution algorithm to identify the optimal modification of a pixel that maximizes the probability of misclassification. The differential evolution algorithm iteratively searches the space of possible pixel modifications. It uses a population of candidate solutions that evolve over time. The success of the one-pixel attack is due to the sensitivity of deep neural networks (DNN) to small perturbations. DNNs can be easily fooled by very small changes that humans would not notice. The differential evolution algorithm works by generating a population of potential solutions, and then combining and modifying these solutions to find the best candidate. Each candidate solution represents a potential pixel change, and the algorithm evaluates the impact of each change on the network classification result. By continually refining the population of solutions, the algorithm eventually converges on a pixel change that causes the desired misclassification. How It Works Executing a one-pixel attack typically involves the use of a differential evolution algorithm, an optimization method that iteratively improves candidate solutions based on a given quality metric. Here is a detailed description of the process: 1. Initialization The algorithm begins by generating a population of candidate solutions. In the context of single-pixel attacks, each candidate represents a potential modification to a single pixel in the image. These candidates are usually randomly initialized within the limits of the image's dimensions and color values. 2. Mutation and Crossover For each candidate solution, the algorithm performs mutation and crossover operations to create a new candidate. Mutation consists of selecting three distinct candidates from the population and creating a new candidate by adding the weighted difference between two of these candidates to the third. Crossing then combines this mutated candidate with the original candidate to produce a trial candidate. This method produces diversity in the candidate population and allows the algorithm to explore the solution space more efficiently. 3. Selection The trial candidate is evaluated according to its impact on the classification result of the neural network. If the trial candidate causes the model to misclassify the image (or increases the probability of target misclassification) more efficiently than the original candidate, it replaces the latter in the population. This selection process is guided by a fitness function which, in this case, measures the probability of misclassification. 4. Iteration The mutation, crossover, and selection steps are repeated over several iterations. With each iteration, the population evolves and the candidates become increasingly effective at causing misclassification. The process continues until the algorithm identifies a change that causes the desired misclassification with a high degree of confidence. 5. Result The final result is the modified image with a single pixel changed, which has successfully fooled the neural network into making an incorrect prediction. Visualization and Analysis Propagation maps offer a new way of visualizing how a single pixel change affects a deep neural network. These maps track the influence of a pixel perturbation as it propagates through the layers of the network, moving from a localized change to a global one. This transformation helps us to understand the power of the one-pixel attack. When we examine the propagation maps, we can see how the impact of a single-pixel change increases as it propagates through the network. Initially, the disturbance may seem insignificant, but as it propagates through the layers of the network, it can lead to real changes in the output of the network. Locality analysis provides a better understanding of attacks at the pixel level. This analysis consists of testing the vulnerability of pixels adjacent to the disrupted pixel. The results show that neighboring pixels often share similar vulnerabilities, indicating that the effectiveness of the attack is not limited to a single point but can affect a wider area. In this way, the attack exploits the receptive fields of the convolutional layers. Each neuron in these layers responds to a specific region of the input image, and changes in this region can significantly influence the neuron's output. Consequently, the success of the attack is linked to the structure and function of these receptive fields rather than to individual neurons or pixels. Variations There are several variations that improve the one-pixel attack. One of these optimizations involves incorporating backdoors during the formation phase of a DNN network. This approach creates vulnerabilities that can be exploited later, making the network more susceptible to one-pixel attacks. Another variation is the use of critical pixel iteration (CriPI) algorithms, which identify and target the pixels most likely to influence network performance. These algorithms use many different techniques, including gradient-based methods and heuristic search strategies, to identify the most significant pixels. Visualization techniques, such as adversity maps and activation maps, also play a crucial role in optimizing one-pixel attacks. Adversity maps highlight the regions of the image that are most sensitive to disturbance, encouraging attackers to concentrate their efforts on these areas. Activation maps show how different parts of the image activate the neurons in the network, revealing which pixels have the greatest influence. By combining these visualization tools with optimization algorithms, attackers can design more effective disruptions, increasing the chances of a successful attack. Applications in All Fields One-pixel attacks are proving effective in many fields, exploiting vulnerabilities in critical systems. In the field of medical imaging, for example, these attacks can trick the AI models used to diagnose diseases, as we saw above in relation to IBM CODAIT's MAX breast cancer detector, resulting in incorrect classifications. In the field of cybersecurity, one-pixel attacks pose a particular threat to facial recognition systems. Face Recognition By modifying a single pixel, attackers can cause these systems to misidentify individuals, thereby compromising security. A notable example of a one-pixel attack in the context of face recognition is presented in a study (*) that explored how adversarial perturbations can be applied to face recognition models. The aim, of course, is to degrade their performance as much as possible. By modifying a single pixel, the attack can cause the face recognition system to misidentify or fail to recognize individuals accurately. This study shows that facial recognition technologies are vulnerable even to small adverse modifications. (*) Cf arXiv:1710.08864v7 "ReFace: Real-time Adversarial Attacks on Face Recognition Systems" "The results show that 67.97% of the natural images in Kaggle CIFAR-10 test dataset and 16.04% of the ImageNet (ILSVRC 2012) test images can be perturbed to at least one target class by modifying just one pixel with 74.03% and 22.91% confidence on average" - arXiv:1710.08864v7 This type of vulnerability extends to other applications that rely on image recognition, such as autonomous driving. In these systems, an attack could lead a vehicle to misinterpret a road sign, resulting in incorrect or even dangerous driving decisions. Defense Mechanisms To mitigate the risk of OPP attacks, several defense mechanisms have been developed, including the Patch Selection Denoiser (PSD) and Multi-Initialized CNNs. These methods improve the robustness of deep learning models by addressing their vulnerability to minor perturbations in the input data. Patch Selection Denoiser One effective approach is the Patch Selection Denoiser (PSD), which removes potential attack pixels from a partial patch of the image. The PSD identifies and eliminates pixels with abnormal patterns, thereby mitigating the impact of the attack. This method is particularly effective because it focuses on small regions of the image, making it more difficult for the attacker to create a successful disruption. Multi-initialized convolutional neural networks (CNNs) are also showing promise in defending against these attacks. These networks use adversarial training methods, where the model is trained with both clean and adversarial examples. By exposing the network to potential attacks during training, the model learns to recognize and resist adverse perturbations. This approach improves the robustness of the network and reduces its vulnerability to single-pixel attacks. Despite this progress, many defense strategies remain vulnerable to adaptive attacks. Attackers are constantly changing their techniques to face existing defenses. This shows how important is the need for ongoing research and development in this area. Multi-Initialized CNNs In another method, Multi-Initialized CNNs improve the resilience of the model by forming several instances of the same network with different initializations. Each initialization leads to a slightly different configuration of the network's weights and biases. During inference, the final prediction is determined by aggregating the outputs of these multiple instances, for example through majority voting or averaging. This ensemble approach reduces the probability that a single pixel perturbation will systematically mislead all instances in the network. The diverse responses of multiple initializations increase the overall robustness of the model, making it less sensitive to small perturbations such as those introduced in single-pixel attacks. Impact on Model Security and Accuracy One-pixel attacks can therefore really compromise the accuracy and reliability of defect detection models, particularly in industrial environments. These attacks can result in false positives or negatives, leading to increased manufacturing costs and reduced profitability. For example, a defect detection system in a manufacturing plant may incorrectly classify a faulty product as non-defective due to a pixel attack, resulting in product recalls and financial losses. The importance of robust security measures in AI applications is well understood. Adversarial attacks such as the one-pixel attack call into question the reliability of AI at the heart of critical applications. Not only do they undermine their effectiveness, but they also call into question the confidence that businesses need to have in them. Conclusion The reality of the effectiveness of one-pixel attacks highlights a fundamental tension in the development of AI: the trade-off between model complexity and robustness. As deep learning models become more sophisticated, they can also become more sensitive to subtle perturbations. This paradox calls for a re-evaluation of our approach to AI design, potentially favoring simpler, more interpretable models in critical applications. It also highlights the need for a complete approach to AI security that goes beyond simple model architecture and includes data integrity, system design, and operational safeguards. As AI continues to become part of our daily lives, we must ensure its resilience in the face of such attacks. It appears that it becomes not only a technical challenge but also a societal imperative.
Editor's Note: The following is an article written for and published in DZone's 2024 Trend Report, Enterprise Security: Reinforcing Enterprise Application Defense. With organizations increasingly relying on cloud-based services and remote work, the security landscape is becoming more dynamic and challenging than ever before. Cyberattacks and data breaches are on the rise, with high-profile organizations making headlines regularly. These incidents not only cause significant financial loss but also result in irreparable reputational damage and loss of customer trust. Organizations need a more robust security framework that can adapt to the ever-evolving security landscape to combat these threats. Traditional perimeter-based security models, which assume that everything inside the network is trustworthy, are proving to be insufficient in handling sophisticated cyber threats. Enter zero trust, a security framework built on the principle of "never trust, always verify." Instead of assuming trust within the network perimeter, zero trust mandates verification at every access attempt, using stringent authentication measures and continuous monitoring. Unlike traditional security models that often hinder agility and innovation, this framework empowers developers to build and deploy applications with security as a core component. By understanding the core principles of zero trust, developers can play a crucial role in fortifying an organization's overall security posture, while maintaining development velocity. Core Principles of Zero Trust Understanding the core principles of zero trust is crucial to successfully implementing this security framework. These principles serve as a foundation for building a secure environment where every access is continuously verified. Let's dive into the key concepts that drive zero trust. Identity Verification The core principle of zero trust is identity verification. This means that every user, device, and application accessing organizational resources is authenticated using multiple factors before granting access. This often includes multi-factor authentication (MFA) and strong password policies. Treating every access attempt as a potential threat can significantly reduce an organization's attack surface. Least-Privilege Access The principle of least privilege revolves around limiting user access to only the minimum necessary resources to perform their specific tasks. By limiting permissions, organizations can mitigate the potential damage caused by a security breach. This can be done by designing and implementing applications with role-based access controls (RBAC) to reduce the risk of insider threats and lateral movement within the network. Micro-Segmentation Zero trust advocates for micro-segmentation to further isolate and protect critical assets. This involves dividing the network into smaller, manageable segments to prevent lateral movement of threats. With this, organizations isolate potential breaches and minimize the impact of a successful attack. Developers can support this strategy by designing and implementing systems with modular architectures that can be easily segmented. Continuous Monitoring The zero-trust model is not static. Organizations should have robust monitoring and threat detection systems to identify and respond to suspicious activities. A proactive monitoring approach helps identify anomalies and threats before they can cause any harm. This involves collecting and analyzing data from multiple sources like network traffic, user behavior, and application logs. Having all this in place is crucial for the agility of the zero-trust framework. Assume Breach Always operate under the assumption that a breach will occur. Rather than hoping to prevent all attacks, organizations should focus on quick detection and response to minimize the impact and recovery time when the breach occurs. This can be done by implementing well-defined incident response procedures, regular penetration tests and vulnerability assessments, regular data backups, and spreading awareness in the organization. The Cultural Shift: Moving Toward a Zero-Trust Mindset Adopting a zero-trust model requires a cultural shift within the organization rather than only a technological implementation. It demands collaboration across teams, a commitment to security best practices, and a willingness to change deeply integrated traditional mindsets and practices that have governed IT security for some time. To understand the magnitude of this transformation, let's compare the traditional security model with the zero-trust approach. Traditional Security Models vs. Zero Trust With traditional security models, organizations rely on a strong perimeter and focus on protecting it with firewalls and intrusion detection systems. The assumption is that if you could secure the perimeter, everything inside it is trustworthy. This worked well in environments where data and applications were bounded within corporate networks. However with the rise of cloud-based systems, remote work, and BYOD (bring your own device) policies, the boundaries of these networks have become blurred, thus making traditional security models no longer effective. Figure 1. Traditional security vs. zero trust The zero-trust model, on the other hand, assumes that threats can come from anywhere, even from within the organization. It treats each access attempt as potentially malicious until proven otherwise. This is why the model requires ongoing authentication and authorization and is able to anticipate threats and take preventive actions. This paradigm shift requires a move away from implicit trust to a model where continuous verification is the norm. Changing Mindsets: From Implicit Trust to Continuous Verification Making this shift isn't just about implementing new technologies but also about shifting the entire organizational mindset around security. Zero trust fosters a culture of vigilance, where every access attempt is scrutinized, and trust must be earned every time. That's why it requires buy-in from all levels of the organization, from top management to frontline employees. It requires strong leadership support, employee education and training, and a transformation with a security-first mindset throughout the organization. Benefits and Challenges of Zero Trust Adoption Although the zero-trust model provides a resilient and adaptable framework for modern threats, the journey to implementation is not without its challenges. Understanding these obstacles, as well as the advantages, is crucial to be able to navigate the transition to this new paradigm and successfully adopt the model to leverage its full potential. Some of the most substantial benefits of zero trust are: Enhanced security posture. By eliminating implicit trust and continuously verifying user identities and device compliance, organizations can significantly reduce their attack surface against sophisticated threats. Improved visibility and control over network activities. By having real-time monitoring and detailed analytics, organizations gain a comprehensive view of network traffic and user behavior. Improved incident response. Having visibility also helps for quick anomaly and potential threat detection, which enables fast and effective incident response. Adaptability to modern work environments. Zero trust is designed for today's dynamic workspaces that include cloud-based applications and remote work environments. It enables seamless collaboration and secure access regardless of location. While the benefits of zero trust are significant, the implementation journey is also covered in challenges, the most common being: Resistance to change. To shift to a zero-trust mindset, it is necessary to overcome entrenched beliefs and behaviors in the organization that everything inside the network can be trusted and gain buy-in from all levels of the organization. Additionally, employees need to be educated and made aware of this mindset. Balancing security with usability and user experience. Implementing strict access control policies can impact user productivity and satisfaction. Potential costs and complexities. The continuous verification process can increase administrative overload as well as require a significant investment in resources and technology. Overcoming technical challenges. The zero-trust model involves changes to existing infrastructure, processes, and workflows. The architecture can be complex and requires the right technology and expertise to effectively navigate the complexity. Also, many organizations still rely on legacy systems and infrastructure that may not be compatible with zero-trust principles. By carefully considering the benefits and challenges of an investment in zero-trust security, organizations can develop a strategic roadmap for implementation. Implementing Zero Trust: Best Practices Adopting the zero-trust approach can be a complex task, but with the right strategies and best practices, organizations can overcome common challenges and build a robust security posture. Table 1. Zero trust best practices Practice Description Define a clear zero-trust strategy Establish a comprehensive roadmap outlining your organization's goals, objectives, and implementation timeline. Conduct a thorough risk assessment Identify existing vulnerabilities, critical assets, and potential threats to inform your zero-trust strategy and allocate resources. Implement identity and access control Adopt MFA and single sign-on to enhance security. Implement IAM to enforce authentication and authorization policies. Create micro-segmentation of networks Divide your network into smaller segments to isolate sensitive systems and data and reduce the impact of potential breaches. Leverage advanced threat protection Employ artificial intelligence and machine learning tools to detect anomalies and predict potential threats. Continuously monitor Maintain constant vigilance over your system with continuous real-time monitoring and analysis of security data. Conclusion The zero-trust security model is an essential component of today's cybersecurity landscape due to threats growing rapidly and becoming more sophisticated. Traditional security measures are not sufficient anymore, so transitioning from implicit trust to a state where trust is constantly checked adds a layer of strength to an organization's security framework. However, implementing this model will require a change in organizational culture. Leadership must adopt a security-first mindset that involves every department and employee contributing to safety and security. Cultural transformation is crucial for a new environment where security is a natural component of everyone's activities. Implementing zero trust is not a one-time effort but requires ongoing commitment and adaptation to new technologies and processes. Due to the changing nature of threats and cyber attacks, organizations need to keep assessing and adjusting their security measures to stay ahead of potential risks. For all organizations looking to enhance their security, now is the best time to begin the zero-trust journey. Despite appearing as a complex change, it has long-term benefits that outweigh the challenges. Although zero trust can be explained as a security model that helps prevent exposure to today's threats, it also represents a general strategy to help withstand threats in the future. Here are some additional resources to get you started: Getting Started With DevSecOps by Caroline Wong, DZone Refcard Cloud-Native Application Security by Samir Behara, DZone Refcard Advanced Cloud Security by Samir Behara, DZone Refcard "Building an Effective Zero Trust Security Strategy for End-To-End Cyber Risk Management" by Susmitha Tammineedi This is an excerpt from DZone's 2024 Trend Report, Enterprise Security: Reinforcing Enterprise Application Defense.Read the Free Report
Editor's Note: The following is an article written for and published in DZone's 2024 Trend Report, Enterprise Security: Reinforcing Enterprise Application Defense. Access and secrets management involves securing and managing sensitive information such as passwords, API keys, and certificates. In today's cybersecurity landscape, this practice is essential for protecting against breaches, ensuring compliance, and enhancing DevOps and cloud security. By implementing effective secrets management, organizations can reduce risk, improve operational efficiency, and respond to incidents more quickly. For developers, it provides a secure, convenient, and collaborative way to handle sensitive information, allowing them to focus on coding without worrying about the complexities of secure secrets handling. This article explores the importance of access and secrets management, why organizations should care, and how it benefits developers. Access and Secrets Management: Recent Industry Shifts As we continue to embrace cloud-native patterns in our development environments, new terms surface. "Decentralized" is a newer term (at least to me) as there's growing traction for fast development cycles using a decentralized approach with the cloud. Decentralization improves scalability and security by isolating sensitive data and reducing the risk of large-scale breaches. Cloud security and identity management ensure that authentication and authorization processes are more robust and flexible, protecting user identities across a distributed environment. An open-source tool example is Hyperledger Aries, part of the Hyperledger Foundation under the Linux Foundation. It provides the infrastructure for building, deploying, and using interoperable decentralized identity solutions. Aries provides the tools and libraries necessary for creating and managing decentralized identities based on verifiable credentials. Aries focuses on interoperability, ensuring that credentials issued by one party can be verified by another, regardless of the underlying system. Aries includes support for secure messaging and protocols to ensure that identity-related data is transmitted securely. An excellent example of leveraging blockchain technology in AWS is the Managed Block Chain Identities. This service facilitates secure and efficient identity management, where identities are verified and managed through a decentralized network, ensuring robust security and transparency. Let's look into another concept: zero-trust architecture. Zero-Trust Architecture Unlike traditional security models that rely on a well-defined perimeter, zero-trust architecture (ZTA) is a cybersecurity framework that assumes no user or device, inside or outside the network, can be trusted by default. This model requires strict verification for every user and device accessing resources on a private network. The core principle of zero trust is "never trust, always verify," ensuring continuous authentication and authorization. Figure 1. Zero-trust architecture One of the key components of ZTA is micro-segmentation, which divides the network into smaller, more isolated segments to minimize the impact of potential breaches. This approach limits lateral movement within the network, therefore containing threats and reducing the attack surface. By implementing micro-segmentation, organizations can achieve finer-grained control over their network traffic, further supporting the principle of least privilege. ZTA employs robust identity and access management (IAM) systems to enforce least-privilege access, ensuring users and devices only have the permissions necessary for their roles. By continuously verifying every access request and applying the least-privilege principle, ZTA can effectively identify and mitigate threats in real time. This proactive approach to security, grounded in micro-segmentation and least-privilege access, aligns with regulatory compliance requirements and enhances overall resilience against cyberattacks. Another additional security feature is multi-factor authentication (MFA). Let's have a look at it. MFA and Ways to Breach It Advancements in MFA involve enhancing security by requiring multiple forms of verification before granting access to systems and data. These advancements make it harder for attackers to gain unauthorized access since they need multiple pieces of identification to authenticate. However, MFA can be compromised with "MFA prompt bombing," a key concern for security. Imagine an attacker who has stolen a password and tries to log in, causing the user's device to receive multiple MFA prompts. They hope the user will either accept the prompt because they think it's legitimate or accept it out of frustration to stop the constant notifications. Threat intelligence from ZDnet reveals how the hacking group, 0ktapus, uses this method. After phishing login credentials, they bombard users with endless MFA prompts until one is accepted. They might also use social engineering, like posing as Uber security on Slack, to trick users into accepting a push notification. Additionally, 0ktapus employs phone calls, SMS, and Telegram to impersonate IT staff and either harvests credentials directly or exploits MFA fatigue. Behavioral Analytics With AI for Access Management As cybersecurity threats grow more sophisticated, integrating AI and machine learning (ML) into access management systems is becoming crucial. AI technologies are continuously enhancing IAM by improving security, streamlining processes, and refining user experiences. Key implementations include: User behavior analytics (UBA) – AI-driven UBA solutions analyze user behavior patterns to detect anomalous activities and potential security threats. For example, accessing sensitive data at unusual times or from unfamiliar locations might trigger alerts. Adaptive authentication – AI-powered systems use ML algorithms to assess real-time risks, adjusting authentication requirements based on user location, device type, and historical behavior. For example, suppose a user typically logs in from their home computer and suddenly tries to access their account from a new or unfamiliar device. In that case, the system might trigger additional verification steps. Identity governance and administration – AI technologies automate identity lifecycle management and improve access governance. They accurately classify user roles and permissions, enforce least privilege, and streamline access certification by identifying high-risk rights and recommending policy changes. Core Use Cases of Access and Secrets Management Effective access and secrets management are crucial for safeguarding sensitive data and ensuring secure access to resources. It encompasses various aspects, from IAM to authentication methods and secrets management. Typical use cases are listed below: IAM – Manage identity and access controls within an organization to ensure that users have appropriate access to resources. This includes automating user onboarding processes to assign roles and permissions based on user roles and departments and performing regular access reviews to adjust permissions and maintain compliance with security policies. Authentication and authorization – Implement and manage methods to confirm user identities and control their access to resources. This includes single sign-on (SSO) to allow users to access multiple applications with one set of login credentials and role-based access control to restrict access based on the user's role and responsibilities within the organization. Secrets management – Securely manage sensitive data such as API keys, passwords, and other credentials. This involves storing and rotating these secrets regularly to protect them from unauthorized access. Additionally, manage digital certificates to ensure secure communication channels and maintain data integrity across systems. Secrets Management: Cloud Providers and On-Premises Secrets management is a critical aspect of cybersecurity, focusing on the secure handling of sensitive information required to access systems, services, and applications. What constitutes a secret can vary but typically includes API keys, passwords, and digital certificates. These secrets are essential for authenticating and authorizing access to resources, making their protection paramount to prevent unauthorized access and data breaches. Table 1 environment overview features benefits Azure Key Vault A cloud service for securely storing and accessing secrets Secure storage for API keys, passwords, and certificates; key management capabilities Centralized secrets management, integration with Azure services, robust security features AWS Secrets Manager Manages secrets and credentials in the cloud Rotation, management, and retrieval of database credentials, API keys, and other secrets Automated rotation, integration with AWS services, secure access control On-premises secrets management Managing and storing secrets within an organization's own infrastructure Secure vaults and hardware security modules for storing sensitive information; integration with existing IT infrastructure Complete control over secrets, compliance with specific regulatory requirements, enhanced data privacy Encrypted storage Uses encryption to protect secrets stored on-premises or in the cloud Secrets are stored in an unreadable format, accessible only with decryption keys Enhances security by preventing unauthorized access, versatile across storage solutions HashiCorp Vault Open-source tool for securely accessing secrets and managing sensitive data Dynamic secrets, leasing and renewal, encryption as a service, and access control policies Strong community support, flexibility, and integration with various systems and platforms Keycloak Open-source IAM solution Supports SSO, social login, and identity brokering Free to use, customizable, provides enterprise-level features without the cost Let's look at an example scenario of access and secrets management. Use Case: Secured Banking Solution This use case outlines a highly secured banking solution that leverages the Azure AI Document Intelligence service for document recognition, deployed on an Azure Kubernetes Service (AKS) cluster. The solution incorporates Azure Key Vault, HashiCorp Vault, and Keycloak for robust secrets management and IAM, all deployed within the AKS cluster. However, this use case is not limited to the listed tools. Figure 2. Banking solutions architecture The architecture consists of the following components: The application, accessible via web and mobile app, relies on Keycloak for user authentication and authorization. Keycloak handles secure authentication and SSO using methods like biometrics and MFA, which manage user sessions and roles effectively. For secrets management, Azure Key Vault plays a crucial role. It stores API keys, passwords, and certificates, which the banking app retrieves securely to interact with the Azure AI Document Intelligence service. This setup ensures that all secrets are encrypted and access controlled. Within the AKS cluster, HashiCorp Vault is deployed to manage dynamic secrets and encryption keys. It provides temporary credentials on demand and offers encryption as a service to ensure data privacy. The application utilizes the Azure AI Document Intelligence service for document recognition tasks. Access to this service is secured through Azure Key Vault, and documents are encrypted using keys managed by HashiCorp Vault. Conclusion Access and secrets management is crucial for safeguarding sensitive information like passwords and API keys in today's cybersecurity landscape. Effective management practices are vital for preventing breaches, ensuring compliance, and enhancing DevOps and cloud security. By adopting robust secrets management strategies, organizations can mitigate risks, streamline operations, and respond to security incidents swiftly. Looking ahead, access and secrets management will become more advanced as cyber threats evolve. Expect increased use of AI for automated threat detection, broader adoption of decentralized identity systems, and development of solutions for managing secrets in complex multi-cloud environments. Organizations must stay proactive to protect sensitive information and ensure robust security. This is an excerpt from DZone's 2024 Trend Report, Enterprise Security: Reinforcing Enterprise Application Defense.Read the Free Report
Editor's Note: The following is an article written for and published in DZone's 2024 Trend Report, Enterprise Security: Reinforcing Enterprise Application Defense. Threat hunting is a proactive cybersecurity strategy that actively searches for hidden threats throughout an organization's entire digital environment. Unlike traditional security measures that primarily react to incidents, threat hunting assumes a breach has already occurred and aims to identify malicious activity before it escalates. By analyzing vast amounts of data from networks, endpoints, and cloud environments, organizations can uncover suspicious patterns, neutralize threats, and significantly reduce their risk of a successful cyberattack. This article sets the overall context and scope for implementing threat detection and hunting in software systems. We will explore new-age practices, advanced tooling, and the integration of AI in threat detection, equipping organizations with the knowledge and tools to bolster their security defenses. Threat Hunting Conventional cybersecurity measures — like intrusion detection system, intrusion prevention system, antivirus, and malware supervision — primarily operate reactively, relying on predefined signatures and alerts to detect known threats such as common malware and viruses. In contrast, threat hunting is a proactive manual or semi-automated process that actively seeks out hidden threats, including advanced persistent threats (APTs), zero-day vulnerabilities, and insider threats. While traditional tools provide automated, broad coverage, they often miss sophisticated threats that evade detection. Threat hunting involves deep, hypothesis-driven investigations to uncover unknown threats, focusing on behavioral anomalies and indicators of compromise (IOCs). This proactive approach enhances an organization's security posture by decreasing the time that threats remain undetected and adapting to the evolving threat landscape. Threat Modeling vs. Threat Hunting Threat modeling is a proactive process that identifies potential vulnerabilities in a system before it's built. It helps prioritize security controls. Threat hunting is both proactive and investigative, focusing on identifying active threats within identified compartments or scope. While different, they complement each other. Threat modeling informs threat hunting by highlighting potential targets, while threat hunting can reveal vulnerabilities missed in modeling. Table 1. Threat modeling vs. threat hunting Features Threat Modeling Threat Hunting Intent Dry run — identify potential risks and vulnerabilities in a system or application Threat simulation — proactively detect anomalies and vulnerability threats within an environment Approach Preventive, theoretical approach Proactive, detective approach Phase Performed during the design and early development phases Conducted toward the end of implementation and during maintenance Methodology Threat identification, risk assessment, mitigation planning Hypothesis-driven, data-driven analysis, anomaly detection Result Mitigation strategies, security controls Threat identification, incident response, and security measure enhancements Modeling tools Threat modeling frameworks (STRIDE, PASTA, LINDDUN, VAST), diagramming mapping Endpoint detection, network analysis, security information, event management, etc. Expertise ISO consultant, security architects, developers, analysts ISO consultant, security analysts, incident responders, threat intelligence analysts Relationship Threat modeling identifies potential vulnerabilities that can be targeted by threat hunting Threat hunting can uncover vulnerabilities that were not previously identified through threat modeling AI: The Double-Edged Sword of Threat Hunting Threat hunting is increasingly becoming an arena for AI competition. The cyber threat landscape is a continuous arms race, with AI serving as a powerful tool for both attackers and defenders. Malicious actors leverage AI to automate attacks and develop sophisticated, adaptive malware. In response, organizations are turning to AI-powered threat hunting solutions to proactively detect and respond to these evolving threats. AI tools excel at analyzing vast amounts of data in real time, uncovering hidden patterns and anomalies that would be challenging for humans to detect. By integrating machine learning (ML) with threat modeling, AI continuously learns and adapts, enhancing threat detection and enabling the proactive identification and prediction of future attacks. Combining continuous learning from ML models with human expertise and traditional security controls creates a robust defense that is capable of outsmarting even the most sophisticated adversaries. AI-Driven Integration of Open-Source Intelligence in Threat Modeling The integration of AI and continuous open-source intelligence in threat modeling has revolutionized the ability to detect and respond to emerging threats. However, it also introduces new challenges and potential threats. Below is a summary of these aspects: Table 2. Threats and challenges introduced by AI-driven threat modeling Aspects Examples New threats introduced by AI AI-powered attacks Sophisticated phishing, evasion techniques, automated attacks Automation of attacks Speed and scale, targeting and personalization Challenges to threat modeling Dynamic threat landscape Evolving threats, predicting AI behaviors and AL/ML opacity of intermediate state of models Data overload Volume of data, quality, and relevance Bias and false positives Training data bias, false alarms Complexity and transparency Algorithm complexity, lack of transparency Addressing challenges Regular hypothesis tuning Continuous AI model updates with diverse data Human-AI collaboration Human-AI integration for validated results Advanced filtering techniques Filtering and prioritization focused on context Adoptable, transparent, and governed Development of transparent, governed AI models with audits By addressing these challenges and leveraging AI's strengths, organizations can significantly enhance their threat modeling processes and improve their overall security posture. While AI plays a crucial role in processing vast amounts of open-source intelligence, its integration also introduces new challenges such as AI-powered attacks and data overload. To effectively counter these threats, a balanced approach that combines human expertise with advanced AI is essential. Furthermore, continuous learning and adaptation are vital for maintaining the effectiveness of threat modeling in the face of evolving cyber threats. Enabling Threat Detection in Software Effective threat detection demands a practical, end-to-end approach. Integrating security measures across the software lifecycle that cut across the enterprise technology stack is essential. By implementing a layered defense strategy and fostering a security-conscious culture, organizations can proactively identify and mitigate threats. Key Steps of Threat Hunting Below are dedicated stages of and steps for approaching an effective enterprise-wide threat detection strategy, along with practical examples, based on threat modeling. Stage One: Preparation and Planning ☑ Define scope: focus on specific areas such as network, endpoints, and cloud — e.g., protect transaction systems in a financial institution ☑ Identify critical assets: determine high-value targets — e.g., patient records in healthcare and payment card information ☑ Develop hypotheses: formulate educated guesses about potential threats — e.g., brute force attack indicated by failed login attempts ☑ Establish success criteria: set metrics for effectiveness — e.g., detect threats within 24 hours ☑ Assemble team: identify required skills and assign roles — e.g., include a network analyst, forensic investigator, and threat intelligence expert Stage Two: Data Collection and Analysis ☑ Identify data sources: use SIEM, EDR, network logs, etc. — e.g., collect logs from firewalls and servers ☑ Collect and normalize data: standardize data for analysis — e.g., ensure consistent timestamping ☑ Enrich data with context: add threat intelligence — e.g., correlate IP addresses with known threats ☑ Analyze for anomalies: identify unusual patterns — e.g., use ML for behavior deviations ☑ Correlate data points: connect related data to uncover threats — e.g., link unusual login times with network traffic Stage Three: Investigation and Response ☑ Validate findings: confirm identified threats — e.g., analyze files in a sandbox ☑ Prioritize threats: assess impact and likelihood — e.g., prioritize ransomware over phishing ☑ Develop response plan: outline containment, eradication, and recovery steps — e.g., isolate systems and restore from backups ☑ Implement countermeasures: mitigate threats — e.g., block malicious IP addresses ☑ Document findings: record details and lessons learned — e.g., document incident timeline and gaps Stage Four: Continuous Feedback and Improvement ☑ Measure effectiveness: evaluate hunting success — e.g., improved detection and response times ☑ Adjust hypotheses: update based on new insights — e.g., include new attack vectors ☑ Update playbooks: refine hunting procedures — e.g., add new detection techniques ☑ Share knowledge: disseminate findings to the team — e.g., conduct training sessions ☑ Stay informed: monitor emerging threats — e.g., subscribe to threat intelligence feeds Figure 1. Threat hunting process By following these steps, organizations can enhance their threat hunting capabilities and improve their overall security posture. Bridging the Gap: How Detection Engineering Complements Threat Hunting Detection engineering focuses on building a robust foundation of security controls to protect against known threats. By developing and refining detection rules, leveraging SIEM systems, and automating alerts, organizations can effectively identify and respond to malicious activity. Continuous testing and validation, along with the integration of threat intelligence, ensure that these defenses remain up to date and effective. While detection engineering is vital for maintaining strong defenses, it is not foolproof. Even the most sophisticated detection systems can be bypassed by APTs and other stealthy adversaries. This is where threat hunting steps in: By proactively searching for hidden threats that have evaded existing defenses, threat hunting uncovers IOCs and behavioral anomalies that automated systems might miss. While detection engineering provides the necessary tools and infrastructure to recognize known threats, threat hunting extends this capability by exploring the unknown, investigating subtle signs of compromise, and validating the effectiveness of existing controls. When detection engineering and threat hunting are combined, they create a powerful synergy that significantly enhances an organization's cybersecurity posture. Detection engineering provides a robust framework for identifying and responding to known threats efficiently, ensuring that security systems are well prepared to handle familiar risks. On the other hand, threat hunting takes a proactive stance, continuously challenging and improving these systems by uncovering previously unknown threats and refining detection strategies. This dual approach not only strengthens defenses against a wide spectrum of cyberattacks but also promotes a culture of continuous improvement, allowing organizations to address both known and emerging threats with agility and precision. By integrating these two disciplines, organizations can build a comprehensive and adaptive defense strategy, greatly enhancing their overall resilience against evolving cyber threats. Key Considerations Around Effective Threat Hunting In a complex cybersecurity landscape, effective threat hunting requires more than just the right tools; it demands a strategic approach that considers various crucial aspects. This section delves into the key factors that contribute to successful threat hunting operations, including the roles and responsibilities of different team members, the importance of diverse data sources, and the balance between automation and human expertise. By understanding these elements and integrating them into your threat hunting strategy, organizations can proactively identify threats, reduce dwell time, and improve their overall incident response capabilities. Table 2. Effective threat handling aspects Aspects Details Expected outcomes Proactive threat identification, reduced dwell time, improved incident response Roles and responsibilities Threat hunters (who lead threats simulation), analysts (data analysis for hypothesis), responders (mitigate actors for threats) Sources Open-source data, commercial threat intelligence feeds, intelligence-sharing communities Incorporation Enriching threat hunting hypotheses, validating findings, updating hunting playbooks Balance Combine human expertise with automation for optimal results Tools SIEM, EDR, SOAR, AI-powered analytics platforms Continuous learning Attend industry conferences, webinars, and training Community engagement Participate in security forums and communities Conclusion In today's increasingly complex cyber threat landscape, it is essential to anticipate and address threats before they materialize. By implementing the outcomes of threat modeling hypotheses, organizations can drive continuous improvement and identify key areas for enhancement. Collaboration is equally crucial — partnering with like-minded organizations for joint hackathons and drills fosters shared learning, best practices, and heightened preparedness. Regular chaos-themed drills further build resilience and readiness for real-world incidents. Investing in AI-driven tools and integrating AI into threat simulation and anomaly detection are no longer optional but necessary. AI and ML models, with their ability to retain and learn from past patterns and trends, provide continuous feedback and improvement. This enhances threat detection by identifying subtle patterns and anomalies within vast datasets, keeping organizations one step ahead of emerging threats. Ultimately, continuous proactive threat hunting ensures a robust defense against the ever-evolving threat landscape. Adopting these proactive threat hunting principles and practices is essential for staying ahead of threats and malicious stealth actors. By actively seeking out and identifying hidden threats before they can cause damage, organizations can maintain a robust defense. This proactive approach ensures that security teams can detect and neutralize advanced attacks that might evade automated systems, keeping organizations safe and resilient against evolving cyber threats. This is an excerpt from DZone's 2024 Trend Report,Enterprise Security: Reinforcing Enterprise Application Defense.Read the Free Report
Whether on the cloud or setting up your AIOps pipeline, automation has simplified the setup, configuration, and installation of your deployment. Infrastructure as Code(IaC) especially plays an important role in setting up the infrastructure. With IaC tools, you will be able to describe the configuration and state of your infrastructure that are desirable. The popular tools for IaC include Terraform, Pulumi, AWS CloudFormation, and Ansible; each of them has different possibilities for automating the deployment and management of infrastructure both in the cloud and on-premises. With the growing complexity of applications and heightened focus on security in software development, the tools SonarQube and Mend are more predisposed. As explained in my previous article, SonarQube is a code analysis tool aimed at helping developers have high-quality code by spotting bugs and vulnerabilities across several programming languages. SonarQube is very well integrated into pipelines of Continuous Integration/Continuous Deployment, producing continuous feedback while forcing enforcement of coding standards. Mend deals with software composition analysis (SCA) helping organizations manage and secure their open-source OS components. Mend, formerly WhiteSource, is a very well-integrated security solution with IaC tools for improving the security posture of infrastructure deployments. Mend automates vulnerability scanning and management for IaC code, allowing their customers to manage incubated security issues very early in the development cycle. Terraform for Infrastructure as Code Terraform is a HashiCorp-developed tool that enables developers and operations teams to define, provision, and manage infrastructure using a declarative language known as HashiCorp Configuration Language, HCL. HCL2 is the current version. Terraform is a provider-agnostic tool that provides the ability to manage resources across several cloud platforms and services by use of a single tool. Some of Terraform's standout features include: Declarative syntax: This is a way of telling the user what they want, and Terraform basically figures out how to create it. Plan and apply workflow: Terraform's plan command shows what changes will be made before actually applying them. This reduces the risk of unintended modifications. State management: Terraform keeps track of your current state. This will turn on incremental changes and detect drift. Modularity: Reusable modules allow teams to standardize and share infrastructure elements across projects. IaC Tools in the Ecosystem Alongside Terraform, a number of other tools offer different capabilities based on what users need and where they are running out of the IaC tool. AWS CloudFormation: Specifically designed for AWS, it provides deep integration with AWS services but lacks multi-cloud support. Azure Resource Manager (ARM) templates: Similar to CloudFormation, but for Azure resources Google Cloud Deployment Manager: Google Cloud's native IaC solution Pulumi: Allows developers to use familiar programming languages like Python, TypeScript, and Go to define infrastructure Ansible: While primarily a configuration management tool, Ansible can also be used for infrastructure provisioning. Chef and Puppet: Configuration management tools that can be extended for infrastructure provisioning Enhancing Security With Mend With the growth of IaC adoption, the demand for better security management also grows. This is where Mend comes in to provide a robust scanning and securing solution for IaC code. Mend will enable smooth incorporation into the development process as well as continuous security scanning of Terraform and other IaC tools. The following are some ways through which Mend boosts security measures without compromising on productivity: Automated scanning: Mend can scan your IaC code automatically in search of vulnerabilities, misconfigurations, and compliance issues. Early detection: If integrated with CI/CD pipelines, Mend will spot security vulnerabilities at an early stage during the development phase thus reducing cost and effort for fixing them later on. Custom policies: Teams can develop custom security policies to meet their specific needs and compliance requirements. Remediation guidance: Upon detection of a problem, Mend provides clear instructions on what steps should be taken to rectify it helping developers address security concerns promptly. Compliance mapping: Issues identified are mapped by mend as per the particular requirements of different standards or regulations so that organizations can maintain compliance. Continuous monitoring: Even after deployment, Mend continues to monitor your infrastructure for new vulnerabilities or drift from secure configurations. Integration with DevOps tools: Mend integrates with famous version control systems, CI/CD platforms, and ticketing systems, making it part of existing workflows. This proactive approach to security allows teams to move fast and innovate while significantly minimizing the risk of security breaches, misconfigurations, and compliance violations when they adopt Mend in their IaC practices. Along with Terraform, Mend supports the following IaC environments and their configuration files: Bicep CloudFormation Kubernetes ARM Templates Serverless Helm Integrate Mend With GitHub Mend provides several integration options and tools that GitHub users can use to further drive security and vulnerability management in their repositories. Overview of Mend's Presence on GitHub Mend for GitHub.com App This GitHub App has both SCA and SAST capabilities. It can be installed directly from the GitHub Marketplace to allow easy integration with your repositories. Mend Bolt Mend Bolt performs repository scans looking for vulnerabilities in open-source components. It is available free of cost as an app on the GitHub Marketplace, supporting over 200 programming languages while supporting the following features: Scanning: This happens automatically after every "push." It detects vulnerabilities in open source libraries and has a five-scan per-day limit per repository. Opening issues for vulnerable, open source libraries Dependency tree management, along with the visualizing of dependency trees Checks for suggested fixes for vulnerabilities Integration with GitHub Checks stops pull requests with new vulnerabilities from getting merged. Mend Toolkit Mend maintains a GitHub Organization, "mend-toolkit", containing various repositories that host integration knowledge bases, examples of implementation, and tools. This includes: Mend implementation examples Mend SBOM Exporter CLI Parsing scripts for YAML files Import tools for SPDX or CSV SBOM into Mend Mend Examples Repository Under the mend-toolkit organization, there is a "mend-examples" repository with examples of several scanning and result-pulling techniques in Mend. This includes, among other things: SCM integration Integrating self-hosted repo setup Integration of CI/CD Examples of policy checks Mend prioritizes scans by language Terms Mend SAST and Mend SCA implementations Set Up Mend for GitHub In this article, you will learn how to set up Mend Bolt. 1. Install the Mend App Go to the GitHub Marketplace. Click "Install" and select the repositories you want to scan. Install Mend Bolt for GitHub After selecting the repositories, click on Install and complete authorization. 2. Complete the Mend Registration You'll be redirected to the Mend registration page. Complete the registration if you are a new Mend user and click on Submit. Mend Registration 3. Merge the Configuration Pull Request Mend will automatically create a pull request(PR) in your repository. This PR adds a .whitesource configuration file: Mend PR Review the PR and merge it to initiate your first scan. Review and merge the PR 4. Customize Scan Settings Open the .whitesource file in your repository. Modify settings as needed. The key setting to enable IaC scans is enableIaC: true. JSON { "scanSettings": { "enableIaC": true, "baseBranches": ["main"] }, "checkRunSettings": { "vulnerableCheckRunConclusionLevel": "failure", "displayMode": "diff", "useMendCheckNames": true }, "issueSettings": { "minSeverityLevel": "LOW", "issueType": "DEPENDENCY" } } Check the other configuration options (Configure Mend for GitHub.com for IaC). Note: Iac scans can only be performed on base branches. JSON { "scanSettings": { "enableIaC": true, "baseBranches": ["main"] }, "checkRunSettings": { "useMendCheckNames": true, "iacCheckRunConclusionLevel": "failure" } } Commit changes to update your scan configuration. 5. Monitor and Review Results Mend will now scan your repository on each push (limited to 5 scans/day per repo for Mend Bolt). Mend scan report Check the "Issues" tab in your GitHub repository for vulnerability reports. Review the Mend dashboard for a comprehensive overview of your security status. 6. Remediate Issues For each vulnerability, Mend provides detailed information and suggested fixes. Create pull requests to update vulnerable dependencies based on Mend's recommendations. 7. Continuous Monitoring Regularly review Mend scan results and GitHub issues. Keep your .whitesource configuration file updated as your security needs evolve. You have successfully integrated Mend with GitHub, enabling automated security scanning and vulnerability management for your repositories. Along with GitHub, Mend supports, Git Enterprise, GitLab, BitBucket, etc., you can find the supported platforms in the Mend documentation. Conclusion The power of IaC tools like Terraform, combined with robust security solutions such as Mend, sets any infrastructure management base on very strong ground. These technologies and best practices help keep organizations safe while ensuring adaptability and scalability for modern, fast-moving digital environments. Indeed, the importance of integrating security throughout the whole life cycle of our infrastructure cannot be overemphasized as we continue raising the bar on what is possible with infrastructure automation. There are additional best practices like version control, modularization, use of right access permissions, auditing your code for compliance, etc., providing added security to your IaC code.
Apostolos Giannakidis
Product Security,
Microsoft
Kellyn Gorman
Director of Data and AI,
Silk
Boris Zaikin
Lead Solution Architect,
CloudAstro GmBH