Stay Ahead With Linux Security Features
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
security advisory Red Hat Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found 6 articles for you...
102
risk managementLinux securityransomwareLinux Ransomware Attack Breakdown: Strategies for Protection
Ransomware has been making life miserable for IT folks for years now, and you’ve probably heard plenty about how it hits Windows systems . But Linux? Yeah, that’s not off-limits anymore. In fact, attackers are seeing Linux as an appealing target—servers running critical enterprise networks, government systems, and big databases that power everything from websites to operations. Anything important enough to cause chaos if it’s compromised, especially where someone’s willing to shell out money to get it back, gets a big bullseye on it. Sure, the majority of ransomware still goes after Windows machines, but if you’re thinking, “Linux is safe because fewer people target it,” that’s a gamble you don’t want to take these days. The methods attackers use are evolving, and even though Linux ransomware is still less common, the attacks themselves are clever, nasty, and diverse. . What’s scary here isn’t just the damage these attacks cause—encrypted files, downtime, reputation hits, and recovery costs—it’s how they sneak their way onto Linux systems in the first place. They exploit vulnerable setups, outdated software, misconfigurations, and anything careless or overlooked. The attack process itself is almost methodical, like breaking into a house and systematically going through every room. But knowing how these attacks work—and, more importantly, how to stop them—can make a big difference. Let’s break down what’s happening in these Linux-targeted ransomware attacks step by step so you have a clearer picture of the threat. Plus, we’ll talk about how to lock things down and avoid being the next “news headline.” Anatomy of a Linux Ransomware Attack Linux ransomware has become known for the sophistication and diversity of its tactics, methods, and techniques to compromise systems and generate profits for its operators. Ransomware attacks targeting Linux systems are generally carried out in a series of clearly defined steps, beginning with exploiting one or multipleunpatched vulnerabilities and ending with a payday for the attackers. Let’s take a closer look at the anatomy of a Linux ransomware attack, broken down step-by-step, to help you better understand this growing threat to your systems and your data. Step 1: Infection Unlike Windows ransomware variants, which spread via email or mall advertising, Linux ransomware infection relies on vulnerability exploitation. Linux ransomware exploits either unpatched system vulnerabilities or flaws in a service, such as a web server or email server, to obtain access to a target system and compromise files. For instance, the infamous Lilocked ransomware exploits out-of-date versions of the Exim message transfer agent to gain a foothold in a target environment. Rex, another dangerous strain of Linux ransomware, uses vulnerability scanners specific to Drupal, WordPress, Magento, Kerner, Airos, Exagrid, and Jetspeed to detect SQL injection vulnerabilities that can be exploited to gain admin credentials. Once in the target environment, the ransomware operator “phones home” to download a hidden executable by connecting to a predefined list of IP addresses that host the command-and-control (C2) server. At this point, the attacker typically copies the malicious executable to a local directory, such as the Temp folder, and then terminates and removes the script. The malicious payload is now executed in the target environment. Linux ransomware strains often possess privilege escalation capabilities, such as those seen in the notorious Lucifer and NotPetya variants. These advanced features enable ransomware operators to access parts of a system that would be inaccessible without privileged access. While Linux ransomware typically only affects those using the web server that is compromised, privilege escalation can magnify both the scope of an attack and its overall impact. Step 2: Staging This step can be seen as the “housekeeping” portion of a Linux ransomware attack. The ransomware sets itself up for smoothoperation by attending to various items, including moving itself to a new folder and establishing persistence in the target environment, giving it capabilities such as the ability to run at boot, to run when in recovery mode, and to disable recovery mode altogether. At this stage of the attack, the ransomware communicates with the C2 server to negotiate its public key, which the operator generates and places in the ransomware to encrypt the randomly generated symmetric key. Step 3: Scanning Now that ransomware has established persistence and set itself up for success. It is prepared to encrypt target files. The ransomware scans compromised systems for a predefined list of file extensions and cloud file storage repositories of interest, mapping the locations of these files and repositories. Step 4: Encryption The encryption phase of an attack is when the real damage is done. Up until this point, nothing potentially irreversible has happened - the malware has simply set itself up and surveyed the target environment. Now, the ransomware creates an encrypted version of the target files using a random symmetric key. It generates and encrypts the symmetric key with its public key. It then deletes the original version of the files it has encrypted. For every location where files have been encrypted, copies of auto-generated ransom notes are created in multiple formats. Step 5: Extortion Once the encryption process is complete, a ransom note providing explicit payment instructions is displayed as the victim's desktop wallpaper. At this point, the ransomware terminates and deletes itself, as its mission in the target environment is complete. Meanwhile, ransomware operators wait for ransom to be paid in untraceable Bitcoin to a wallet they own. The victim must decide if he or she is willing to pay the ransom in exchange for the decryption of locked files or accept the fact that the files encrypted in the attack are permanently inaccessible. It is often helpful to enlist a ransomware recovery firmat this point, as they can offer advice and, in some cases, locate a decryption key that can be used to recover locked files. Final Thoughts & Best Practices for Protecting Against Linux Ransomware Let’s be real—Linux ransomware might not dominate headlines the way Windows ransomware does, but it’s a growing problem, and ignoring it is a mistake. The good news is that you’re already a step ahead by understanding how these attacks work and what they typically target. But here’s the thing: a lot of these compromises boil down to unpatched systems or sloppy administration. It’s not flashy, but staying on top of patches , cleaning up permissions, and verifying your configurations regularly can go a long way. Don’t assume your server’s safe just because it’s running Linux—that mindset’s outdated. Even small gaps, like a forgotten web server vulnerability or a missed security audit, create an opening for ransomware. And trust me, when ransomware hits, it’s not just a technical headache—it’s scrambling to fix broken systems while everyone else is demanding answers. So, what can you do today? Start with backups —seriously, I’ve seen too many people regret half-baked backup strategies when things go south. Make backups solid, spread them across different media, and test them once in a while. Then, tighten up access controls . If users don’t need access, they shouldn’t have it. IDS and IPS tools might sound like overkill for some setups, but they can be game-changers in spotting weird traffic early. And don’t forget regular audits—it’s boring, I know, but they can unearth issues before attackers do. This isn’t about chasing perfection; it’s about minimizing risk and staying prepared. Linux is resilient, sure, but ransomware doesn’t care about all that—it cares about the cracks. So, close them up! . Ransomware targets Linux systems, causing costly damage. Learn strategies to protect against these attacks effectively.. ransomware, making, miserable, folks,years, you’ve, probably, heard. . Brittany Day
Jun 05, 2025
•
102
risk managementdata integritycomplianceStreamlining Third-Party Risk Management: Benefits and Best Practices
Managing third-party risks is critical to business operations, especially in today’s interconnected global economy. With organizations relying on vendors, suppliers, and contractors more than ever, identifying and mitigating risks associated with these external parties is essential. . Meanwhile, keeping up with the latest advancements in linux security and linux news is crucial for IT departments to protect their systems. Traditionally, third-party risk management (TPRM) processes have been manual, resource-intensive, and error-prone. However, technological advancements have ushered in a new era: TPRM automation . Incorporating automation into third-party risk management enhances accuracy and efficiency, helping businesses make faster, data-driven decisions without compromising on compliance. This article explores how TPRM automation can revolutionize risk management and why businesses should automate third-party risk processes. What Is Third-Party Risk Management Automation? Third-party risk management (TPRM) automation refers to using technology to streamline and automate the processes involved in identifying, assessing, and mitigating risks associated with external partners. Instead of relying on manual methods such as spreadsheets, emails, and phone calls, TPRM automation allows companies to centralize and automate these tasks. Automated systems can continuously monitor third parties for risk indicators, analyze data more efficiently, and provide real-time updates. This not only reduces the time spent managing risks but also helps in the early identification of potential issues, allowing businesses to act proactively. Benefits of Automating TPRM There are several advantages to implementing TPRM automation for businesses of all sizes. Let’s dive into some of the key benefits: Increased Efficiency and Speed Manual risk management processes often involve tedious tasks that can slow down the entire workflow. Automation eliminates the need for repetitive data entry,cross-referencing, and manual follow-ups. With automation tools, you can set predefined workflows, enabling quicker identification and resolution of risks. This increased speed allows businesses to respond to potential threats in real-time rather than after the damage has been done. Cost Savings Reducing manual labor leads to significant cost savings. Organizations can reduce the number of employees required to manage risk by automating third-party risk management processes. The system handles much of the legwork, such as gathering information, assessing risks, and generating reports, freeing up employees to focus on higher-level strategic tasks. Furthermore, automation reduces human error, which can be costly in risk management scenarios. Correcting mistakes often requires additional time, effort, and resources, but automation minimizes this risk, ensuring that the processes are carried out accurately the first time. Improved Accuracy and Data Integrity Manual processes are not only time-consuming but also prone to mistakes. Automating TPRM ensures that data is captured consistently and accurately. This means fewer errors in risk assessments and a more reliable system for tracking risks. Automation tools can integrate with multiple data sources to gather relevant information, ensuring the data you’re working with is up-to-date and precise. Scalability As a business grows, so does its network of third-party relationships. Managing the associated risks can become overwhelming if relying on manual processes. TPRM automation provides scalability, allowing companies to efficiently manage an increasing number of third parties without additional administrative burden. Automated systems can handle large volumes of data and scale to meet your business needs. Key Features of TPRM Automation Tools When considering TPRM automation, it’s essential to understand the features that will impact your business most. While each automation tool may differ, certain features are particularly valuablein open-source third-party risk management tools like OpenVAS: Continuous Monitoring One of the most critical features of a TPRM automation tool is the ability to monitor third-party relationships continuously. This means that even after an initial risk assessment, the system will regularly check for any changes in the vendor’s profile that might indicate increased risk. Whether it's financial instability, regulatory non-compliance, or cybersecurity threats, continuous monitoring helps businesses avoid potential problems. Automated Risk Scoring Automated risk scoring is a valuable feature that allows businesses to assess the risk levels of each third party quickly. The system analyzes various factors such as financial health, compliance records, and past performance to assign a risk score. This helps prioritize which vendors or partners need closer scrutiny or additional risk mitigation strategies. Customizable Workflows Every business has unique needs when it comes to third-party risk management. Customizing workflows allows businesses to tailor the automation process to fit their specific requirements. Whether setting different risk thresholds, automating approval processes, or integrating with other systems, customizable workflows ensure that TPRM automation aligns with the company’s risk management strategy. Centralized Risk Management Dashboard A centralized dashboard gives businesses a real-time view of all third-party risk management activities. This feature overviews current risk levels, pending assessments, and ongoing monitoring efforts. With all information in one place, it’s easier for decision-makers to take action and manage risks more effectively. Challenges of Implementing TPRM Automation While the benefits of TPRM automation are significant, businesses may face certain challenges during implementation. Understanding these challenges can help organizations plan accordingly and mitigate any potential obstacles. Integration with Existing Systems One ofthe biggest challenges is ensuring that TPRM automation tools integrate seamlessly with existing systems. Businesses often have multiple platforms handling different aspects of operations, and integrating a new system can sometimes cause disruptions. Companies need to ensure that the automation tool they choose is compatible with their current infrastructure to avoid any implementation hiccups. Data Security and Privacy Concerns Automating third-party risk management involves handling large amounts of sensitive data. While automation tools are designed to improve security, businesses must still be mindful of potential data breaches or privacy concerns. Implementing strong cybersecurity measures and ensuring compliance with data protection regulations is essential when automating TPRM. Initial Costs and Resource Allocation Although automation can lead to long-term cost savings, the initial implementation costs can be significant. Companies must invest in the right technology, train staff, and allocate resources for successful deployment. However, these costs are a necessary investment for improved risk management in the long run. Best Practices for Adopting TPRM Automation For businesses considering automating their third-party risk management processes, here are some best practices to ensure a smooth transition: Assess Your Current TPRM Program Before implementing automation, it’s crucial to assess your current TPRM program. Identify the manual processes that consume the most time and resources and consider how automation can streamline them. Understanding your business's pain points will help you choose the right automation tool. Choose the Right Automation Tool Not all TPRM automation tools are created equal. Research different options to find one that suits your business’s needs, integrates with your existing systems and offers the features that are most important to you, such as continuous monitoring, risk scoring, and customizable workflows. Train Your Team Automation won’t be effective if your team isn’t equipped to use it. Provide training to your staff to ensure they understand how the system works, how to interpret automated risk reports, and how to respond to alerts. Automation Tool Selection Not all TPRM automation tools are created equal. Research different options to find one that suits your business’s needs integrates with your existing systems, and offers the most important features, such as continuous monitoring, risk scoring, and customizable workflows. For instance, staying updated with linux security and linux news can help you choose automation tools that comply with the latest security standards and technological trends. Ensure that the selected tool seamlessly integrates with your business's IT infrastructure, which might be based on Linux environments. Security Considerations While automation tools are designed to improve security, businesses must still be mindful of potential data breaches or privacy concerns . Implementing strong cybersecurity measures and ensuring compliance with data protection regulations is essential when automating TPRM. Following linux security best practices can provide additional layers of protection. Additionally, keeping up with linux news can inform you about the latest vulnerabilities and patches , helping to keep your automated TPRM systems secure. Our Final Thoughts on Streamlining Third-Party Risk Management Third-party risk management automation is no longer a luxury but a necessity for businesses looking to stay competitive in a fast-paced, risk-laden environment. Automating TPRM helps companies save time, reduce costs, and improve accuracy, all while enhancing their ability to mitigate risks effectively. As the business world becomes increasingly complex, adopting TPRM automation ensures that companies can manage third-party risks with greater confidence and agility. . Keeping up with Linux security advancements safeguards business operations and boosts third-party risk managementefficiency.. managing, third-party, risks, critical, business, operations, especially, today’s, interconnecte. . Brittany Day
Oct 11, 2024
•
102
network securityrisk managementcloud technologyCombining Cyber And Physical Security Strategies For Modern Challenges
Businesses experienced around 130 attacks in network security in 2022. Companies must improve security, as this essential investment maintains GDPR compliance and client trust. . Additionally, keeping up-to-date with physical-cybersecurity trend strategies can be valuable to your cybersecurity health . This article will discuss how cyber and physical security blend, their role in Open-Source Intelligence (OSINT) tools, and how to facilitate this cyber-physical security approach in modern climates. Why Is A Cyber-Physical Security Strategy Important? Cyber-physical security prevents businesses from network security threats. Here are some reasons as to why physical and cybersecurity should blend rather than stay separate: Cyber-physical security threats: Cyberattacks threaten your digital and physical security, so these tools must work together to combat hybrid attacks in network security. Digital assets stored in company buildings: Physical security breaches and data theft could occur if companies physically store digital assets. Cloud-based physical security data: Cloud-based security tools can save storage and improve security scalability. However, storing physical security data could result in network security issues like cloud security breaches and general exposure. How To Blend Cyber And Physical Security For A Futureproof Strategy Let’s discuss mitigating cybersecurity vulnerabilities by incorporating physical security into your online data and network security strategies. Here are a few best practices to consider: Leverage Open-Source Intelligence to Manage Risk Open-Source Intelligence (OSINT) is collecting and analyzing data gathered from open sources to produce actionable intelligence. OSINT successfully converges and scales cyber and physical security to close dangerous coverage gaps, making it a favorite among security teams for providing critical information and threat intelligence. This service offers valuable insights into fake social media accountsmisrepresenting or targeting executives and employees, negative sentiments or protests that could delay travel plans, and planned attacks in network security against physical assets. OSINT identifies vendors doing business with high-risk foreign nationals or nation-states. When appropriately executed, OSINT is a crucial decision and collaboration network security toolkit for business professionals in today's risk management landscape. Lockdown Systems Use cyber-physical security to contain network security threats related to logins. You can initiate a double lockdown if an intruder or employee enters the wrong credentials multiple times. The user’s login platform will shut down to prevent attempts that could lead to network security issues to protect your company from possible exploits in cybersecurity. Your door access keypad will bolt all locks to allow physical security teams to perform an investigation regarding the incident. This dual response mitigates attacks in network security that could occur if an individual entered your digital system with someone else’s. Verifying On-Site Status Prevent users from accessing company resources offsite by requiring them to enter business buildings through Access Control Systems with their keycard or fob. There are API integrations that verify a user so they can only access the company’s login system once their physical presence is validated. Then only on-site employees can reach your sensitive digital assets, lowering the risk of exposure and cybersecurity vulnerabilities. Using Cybersecurity Policies In Your Physical Security Strategy Ensure protection over digital resources stored in your building by implementing physical security policies that can confirm data and network security for such resources. The zero-trust physical security policy prevents internal cloud security breaches by giving each user role-based permissions. Only a limited amount of data faces exposure if an account gets breached, thus protecting all employees in thecompany. Apply role-based access credentials so that on-site users can only access the buildings they need for daily operations and nothing more. Server and sensitive data rooms should install smart door locks so only high-level employees can enter. Cybersecurity Protection For Physical Security Data Here are the benefits of utilizing cloud-based physical security technologies in your online strategy: Remote operation: Use mobile devices or cloud-based control centers to operate door locks and security cameras from anywhere. Alerts and accessible data: Receive alerts about detected network security threats and view them on mobile devices before investigation. Integration: Improve ROI by integrating different network security toolkits to eliminate data silos and enhance data and network security. This strategy, however, comes with the risk of cybersecurity vulnerabilities that give third-party organizations more opportunities to successfully infiltrate your system and operate your security system as they choose. Implement cybersecurity software to keep your physical security data safe and secure. Coordinating Cyber And Physical Security Teams Coordinate your cyber and physical security teams to take a combined approach to data and network security. Since threats can simultaneously concern physical and cybersecurity, both teams must be aware of hazards or risks. Having the teams work together grants them accessible communication and collaboration, eliminating interdepartmental data silos that could hinder security operations. Reduce misunderstandings and heavy workloads by having these teams merge, helping you refine your company and save money that can be spent on other security investments. AI And Analytics Utilize AI and analytics to monitor your security data while merging cyber and physical security. Physical security professionals cannot view and monitor security data consistently for potential network security threats, so companies risk cybersecurity exploits if yourteam does not immediately take care of an incident. AI offers analytics software that notifies your team whenever an abnormality requires investigation. Such software allows you to expand your security camera functions to prevent a security breach rather than record it afterward. Automated Workflows Make your physical and cyber incident strategies more efficient and streamlined by investing in automated workflow software, which can help your security team respond to physical and cybersecurity vulnerabilities in line with a merged cyber-physical security strategy. Once detected, the system creates automated workflows based on your pre-established security response protocols, reducing the time and effort workers must spend on manual integration. Creating this system can strengthen your response to cyber and physical security issues, ensuring no gaps in your data and network security strategy. Our Final Thoughts on How Physical Security Blends With Cybersecurity The security world faces constant changes, and we must understand that physical and cybersecurity need to be combined rather than kept separate. To futureproof your security strategy and fortify your business against the modern threat climate, consider how cyber and physical security are linked and whether they can benefit your security health with cloud-based technologies, OSINT, and cyber-physical processes. . Strengthening physical security plays a vital role in bolstering cybersecurity resilience. Delve into essential techniques to integrate these distinct domains seamlessly.. Cyber-Physical Security, Physical Security Strategies, OSINT Techniques, Cloud Security Management. . Brittany Day
Dec 26, 2022
•
102
security advisoryrisk managementcyber attackNode.js Application Security: Risks, Best Practices and Solutions
Due to its ability to act as the backend server for web applications, Node.js is becoming a trendy platform these days. However, it becomes crucial to take into account Node.js security policies when it comes to the world of microservices. . Open-source backend frameworks have long had security flaws, and every Node.js developer knows the dangers that hackers pose to apps and user data. The article will concentrate on the risks and solutions developers may use to increase the security of their online applications while keeping Node.js security issues in mind. Why Is Node.js Popular in Back-End Development? JavaScript has strong frameworks and libraries and has been around for a while. Still, it has never had any backend platforms that could contend with other programming languages. Node.js can address this problem. Some of the advantages of using Node.js are listed below. Easy to learn: JavaScript proficiency is prevalent among many developers. Node.js uses JavaScript. As a result, picking up Node.js is not difficult and can be learned in a few weeks. Scalability: Scalable network applications are the focus of the design of Node.js.This is why it gained popularity among developers and big businesses so quickly. Flexibility: Node.js gets big thumbs up for allowing developers to create adaptable programs that function flawlessly on any platform. Node.js helped alleviate the concern that apps wouldn't work on various operating systems. Light and fast: Node.js uses a high-performance, open-source JavaScript and WebAssembly engine. In a single asynchronous thread, it responds to requests. This lessens both the CPU and memory load. Your app will become lighter as a result. The possibility that hackers will attempt to find vulnerabilities increases with the framework's popularity. As a result, Node.js security should always be taken care of. Potential Risks for Node.JS Applications Not all security concerns are serious, and here are the primarysecurity considerations on Node.js. Code injection The primary duty of an application developer is to write secure code. However, you cannot ultimately ensure the security of your codebase while using open-source software. Any malware in which the hacker inserts code into the system and forces the application function to run is called a code injection attack. The attacker looks at the sloppy and uncertain data to learn more about your codebase. A common code injection attack that most people run into while developing software is SQL injection. Here, the hackers use malicious SQL code to change the backend database to get sensitive data that is not usually visible. Cross-site request forgery attack You shouldn't ignore the frequent Node.js security vulnerability known as Cross-Site Request Forgery (CSRF). Using a CSRF attack, a web application against which a user has already been authenticated is forced to accept requests from authenticated users. It lets hackers access private information and risks web applications' security and integrity. Hackers utilizing CSRF want to alter the application's state by tricking users into thinking they've received a message or email . Attacks on admin-level users that use CSRF could put the security of the whole web application at risk. Cookies Since every user action on a web application results in cookies kept in the underlying infrastructure, cookies help websites or web apps identify a specific user. The most typical uses of cookies are in shopping carts on eCommerce websites. Because of the cookies, the shopping cart will show you the items you previously selected on the website when you go to the checkout page. However, the issue with Node.js development is when the developer chooses the standard cookie names rather than changes them to meet the needs. Since hackers know the default cookie name, they are likely to attack and quickly get access to user input. Brute-force attacks One of the most frequent threats or risks inany Node.js security checklist is brute force attacks. To gain access to sensitive data, hackers attempt to use random passwords generated at the login endpoints of web applications. The goal of brute forcing is to try millions of different password combinations until they find the one that works for the online application. You must fortify your authentication system for Node.js applications to thwart brute-force attacks. To deal with such unsafe scenarios, you can also restrict the number of login attempts from one IP address and use bcrypt.js to protect the passwords saved in the database. X-powered-By header Many programming languages, by default, use the non-standard HTTP response header known as X-Powered-By. This header identifies the technology used in app development. It enables hackers to take advantage of numerous security flaws related to that specific technology. You can enable or disable this header using server configuration management approaches. Distributed Denial of Service A Distributed Denial of Service (DDoS) assault involves flooding a server, service, or network with excessive internet data. It includes malicious JavaScript code to interfere with the regular server, service, or network traffic. Due to their ability to take advantage of the HTTP processing flaw, Node.js versions 4.0.0 and 4.1.1 have given birth to DDoS attacks. Since they have the potential to destroy your servers, networks, or services, limiting these attacks is crucial to guarantee the smooth functioning of your Node.js apps. Cross-Site Scripting Attack Cross-site scripting attacks are critical risks to be aware of when developing Node.js web applications. Cross-site scripting (XSS) lets attackers change the JavaScript code in a web app using client-side scripting. The end user's browsers cannot determine whether the codebase is trustworthy. Therefore, a hacker can use XSS to send them a malicious script. As a result, they automatically execute it, allowingattackers to access any session tokens, cookies, or other private data. These scripts can also change any HTML page's content, making XSS extremely dangerous. Let's break down Node.js's recommended practices to help you avoid these situations now that you're sufficiently aware of their risks. Best ways to boost Node.JS application security Validation of user data The data coming from the user or another system entity must constantly be verified. The working system is endangered by poor validation, resulting in security exploits. Data validation can be carried out using a node module named validator. Let's explore Node.js's data validation capabilities. JavaScript Localization While enhancing Node.js application security, it's crucial to consider proper localization to ensure the app delivers accurate and meaningful content to users across different regions. JavaScript localization involves adapting your content for various languages and regions, considering local culture, conventions, and regulations. const validator = require('validator'); validator.isEmail('foo@bar.com'); //=> true validator.isEmail('bar.com'); //=> false The data/schema validation can also be done using a module named joi. const joi = require('joi'); try { const schema = joi.object().keys({ name: joi.string().min(3).max(45).required(), email: joi.string().email().required(), password: joi.string().min(6).max(20).required() }); const dataToValidate = { name: "Shahid", email: "abc.com", password: "123456", } const result = schema.validate(dataToValidate); if (result.error) { throw result.error.details[0].message; } } catch (e) { console.log(e); } Prevent SQL injection attacks Your database can be retrieved, added to, or modified byattackers who defeat authentication. SQL injections happen when you ask users for input, such as their id or username, and they insert a SQL statement in its place. This is a typical hacking tactic that could ruin your database. See one example below. textuserID = getRequestString("userID"); textSQL = "SELECT * FROM Users WHERE userID = " + textuserID; Let's examine some of the potential problems. The example retrieves a variable (textuserID) from user input. The user is chosen in the following line of code based on their ID. SQL injection 1=1 The SQL statement appears as follows if your user provides something like 100 OR 1=1 for their userID: SELECT * FROM Users WHERE userID = 100 OR 1=1; Since 1=1 is true, the statement above will return all rows from the Users table. This might be pretty risky if your table contains data like usernames and passwords. How to prevent SQL injection? Parameterized statements: Regardless of the input, they enable your database to distinguish between data and code. Input validations: Additional protection is provided via input validations. Writing your validation logic will allow you to compare input to a list of permitted possibilities. Database with least privilege: Your app is protected from SQL injections if you use database accounts with the very minimum access. Avoid using database accounts with admin permissions in your Node.js application. Sanitize input: You must make sure to remove any input that seems suspect. Checking fields like email addresses , and matching a regular expression might help you achieve that. Data verification through typecasting Since JavaScript is dynamically typed, a value can be of any type. To ensure that only the appropriate value enters the database, you can use the typecasting technique to determine the data type. For instance, typecasting should ensure that a user ID can only be a number and can only accept numbers. As an illustration, consider the code we displayed below. var mysql = require('mysql'); var connection = mysql.createConnection({ host : 'localhost', user : 'me', password : 'secret', database : 'my_db' }); connection.connect(); connection.query( 'UPDATE users SET ?? = ? WHERE ?? = ?', ['first_name',req.body.first_name, ,'id',Number(req.body.ID)], function(err, result) { //... }); In order to verify that ID is always a number, we used Number(req.body.ID). Authentication and authorization Passwords and other sensitive data should be maintained in systems securely to prevent misuse by malicious individuals. We will learn how to save and manage passwords in this part. Password hashing Hashing is a form of one-way encryption. Because it lacks a decryption key, it differs from encryption. Assume your password is Pa55word to see how it works. It will resemble dhkqhuhdhudhuh after being processed by a hashing method You can sign in by entering your password (Pa55word), which is hashed and checked to see whether it matches dhkqhuhdhudhuh. To protect passwords, the Node.js package bcryptjs takes the password and the salt, which says how many times the hashing method should run. The hash and salt are generated using several function calls in the example below. bcrypt.genSalt(saltRounds, function(err, salt) { bcrypt.hash(myPlaintextPassword, salt, function(err, hash) { // Store hashed password in database }); }); Storage You cannot keep a plain text copy of your passwords, whether you use a database or files to store them. You should create the hash and store it in the system. In cases when a password is involved, we typically advise utilizing the varchar(255) data type. You can choose a field with an unlimited length. You can utilize the varchar(60) field using bcrypt because it creates fixed-size hashes of 60 characters. Encryption By using an encryption key, password encryptionenables you to turn your passwords into an unreadable message. The recipient and you both know the mathematical value that serves as the encryption key. The recipient converts the random text to a message that can be read using the encryption key. Encryption is a two-way function. Therefore, you must afterwards decrypt everything you encrypt. User authorization A system with appropriate user roles and permissions stops malicious users from acting without authorization. Each user is given the appropriate roles and rights to establish a proper authorization procedure, allowing them to perform only necessary actions. Using the well-known ACL module, you can create access control lists based on system permission in Node.js. const ACL = require('acl2'); const acl = new ACL(new ACL.memoryBackend()); // guest is allowed to view blogs acl.allow('guest', 'blogs', 'view') // check if the permission is granted acl.isAllowed('joed', 'blogs', 'view', (err, res) => { if(res){ console.log("User joed is allowed to view blogs"); } }); Stop brute-force attacks In brute force attacks, the attackers always continue to attempt to create a random password. Attackers in this situation might think about generating millions of passwords until they come up with the ideal one. Consider utilizing the bcrypt.js package, which will protect the password whenever it is saved in the database. Additionally, you can think about restricting the volume of queries from a single IP. Execute the below code: npm install express-brute --save Try this code: const ExpressBrute = require('express-brute'); const store = new ExpressBrute.MemoryStore(); const bruteforce = new ExpressBrute(store); app.post('/auth', bruteforce.prevent, // error 429 if we hit this route too often function (req, res, next) { res.send('Success!'); } ); SSL security layer Browsers and searchengines use digital certificates, known as SSL certificates, to verify the legitimacy of websites. SSL certificates are one of the most important things to consider when protecting your web apps. Anyone can mimic your website without an SSL certificate and steal vital user information. We must take the actions listed below to generate the SSL Certificate: Establish a Private Key Using the private key, generate a CSR (certificate signing request). Create an SSL certificate using a CSR Integrate session layers To manage sessions in Node.js, we can use express-session middleware. In the express server itself, the session is kept. MemoryStore, the standard server-side session storage, is not intended for use in a real-world setting. It does not grow beyond a single process, leaks memory frequently, and is designed for debugging and development. We must establish a global map and add each session object to manage numerous sessions for multiple users. Global variables in Node.js consume a lot of memory and present severe security risks in applications that are intended for production environments. Utilizing an external session store will help you resolve this. Each session must be saved in the store so that it only ever belongs to one user. Redis is a widely used session store. CSRF attack prevention End users are compelled to do unnecessary activities on authenticated web apps by CSRF attacks. Due to the attacker's lack of access to the falsified request response, CSRF attacks target requests for changes in the application state. State-changing requests can be forced using CSRF. The entire online application may be compromised for administrative users if CSRF occurs. Anti-Forgery Tokens are necessary for Node.js to prevent CSRF. Tokens that are anti-CSRF are used to keep track of user requests, confirm their legitimacy, stop one-click attacks, and more. Request size reduction for DDoS The first thing to think about when dealing with DOS attack defense is restrictingthe actual payload that users can submit to your API/app/service. You can limit the body payload by using a body parser. You can make use of ExpressJS's built-in body parser. const express = require('express'); const app = express();app.use(express.json({ limit: '10kb' })); // Body limit is 10 Prioritize MongoDB access Information is kept in MongoDB as JSON documents. It offers assistance for all fundamental data types. However, MongoDB saves them as BSON (binary-encoded JSON documents). Because it encrypts special characters, MongoDB defends itself against conventional injection attacks like BSON documents. Appropriate error handling When addressing errors, there are a few things to think about. First, don't reveal the information to the user, i.e., don't provide the client with the entire error object. It can have data you don't want to make public, such as pathways, a different library being used, or even secrets. Second, encapsulate routes in a catch clause to prevent Node.js from crashing when a request causes an error. By doing this, attackers are prevented from discovering malicious requests that would crash your application and repeatedly submitting them, causing your program to crash. Securing cookies A cookie stores the details of every activity you take on the website. The site's session cookie keeps track of the options you've made. The new page won't be able to identify your prior actions on other pages without session cookies. Utilizing default cookie names puts your application at risk because attackers can easily detect and use them against you. Use express-session or another middleware cookie session module to fix the issue. Security headers implementation There are many security headers available in HTTP that can prevent well-known attacks. To enable all security headers with a single line of code while utilizing the Express framework, use the helmet module. npm install helmet --save Try this code to use this. const express =require("express"); const helmet = require("helmet"); const app = express(); app.use(helmet()); Conclusion Security flaws and threats have cost businesses thousands of dollars over the years. While data breaches can be costly, sensitive data leaks and stolen information are valuable. We might be unable to stop every attempt an attacker might make to destroy our apps. Still, we can control how much harm our carelessness causes. This article discusses security throughout the entire software development lifecycle, not only the best practices that should be followed when creating applications. You can opt to hire a Node.js development company or consultants if you want to secure your Node.js application. Or need assistance creating data-intensive apps tailored to your company's requirements. . Free-to-use server-side frameworks frequently possess security weaknesses, thus it is crucial for every Node.js programmer to understand the threats and remedies.. Node.js Security, Backend Framework Safety, Microservices Protection. Harikrishna Kundariya. Brittany Day
Aug 26, 2022
•
102
network securityrisk managementsecurity toolsReview of Network Security Monitoring by Richard Bejtlich
The Tao of Network Security Monitoring is one of the most comprehensive and up-to-date sources available on the subject. It gives an excellent introduction to information security and the importance of network security monitoring, offers hands-on examples of almost 30 open source network security tools, and includes information relevant to security managers through case studies, best practices, and recommendations on how to establish training programs for network security staff. . Book Review Author: Richard Bejtlich Publisher: Addison Wesley Pages: 798 Opinion To be honest, this was one of the best books that I've read on network security. Others books often dive too deeply into technical discussions and fail to provide any relevance to network engineers/administrators working in a corporate environment. Budgets, deadlines, and flexibility are issues that we must all address. The Tao of Network Security Monitoring is presented in such a way that all of these are still relevant. One of the greatest virtues of this book is that is offers real-life technical examples, while backing them up with relevant case studies. Network security engineers, system administrations, and security management will find value in this book. It is a must-read for anyone interested in getting into the field, but would still be useful as a reference for the experienced expert. The book is written in an easy to follow manner and is filled with diagrams, tables, screen shots, and relevant examples. Richard Bejtlich attempts to help network engineers go beyond what is offered by today's intrusion detection systems. He provides a basis for developing an entire network security monitoring architecture, which gives administrators a much clearer view of network activity. I highly recommend this book to anyone involved in network security on a day-to-day basis. Inside the Book The Tao of Network Security Monitoring is written in 6 parts with 18 chapters and several appendixes. Part I gives an introduction tonetwork security monitoring, part II introduces available network security tools with examples of usage as well as how the tool can be acquired. Part III and IV outline the network security monitoring process through best practices and case studies while explaining role of those individuals involved. Part V describes what tools and tactics attackers use to evade network security monitoring systems. Part VI, the appendixes, offer a protocol header reference, an intellectual history of network security monitoring, and an introduction to protocol anomaly detection. Chapter 1 offers a decent introduction to information security, but it focuses specifically on background material that is relevant to network security monitoring. Rather than viewing security in a traditional light, Richard Bejtlich offers an explanation that puts threats and vulnerabilities into the concept of risk management. The characteristics of an intruder are given as well as the phases of a typical network compromise. (Reconnaissance, Exploitation, etc.) One of the more interesting parts of this chapter is the author's description of the phrase 'defensible network.' Defensible networks can be monitored, limit an intruder's maneuverability, keep services to a minimum, and can be managed more easily. Chapter 2 goes more deeply into network security. This chapter is slightly more technical, but still offers a high-level explanation of the principles and concepts necessary when developing a network security plan. Chapter 3 continues to prepare the reader to understand the entire network security environment. This chapter offers an introduction to the security perimeter, demilitarized zone, wireless networks, and intranets. It discusses the use of hubs, span ports, taps, inline devices, monitoring architecture, and monitoring administration considerations. After the first three chapters, readers should have a firm understanding of the role the network security plays in an organization. The next seven chapters offer detailed information aboutmany of the network security monitoring tools available to administrators. The author chose to include only software that is presently available for his FreeBSD 4.9 test platform. However, this should not be a discouraging factor for Linux readers. The sources and binaries for nearly all of the software examined is also available for Linux. Chapter 5 focuses on 'full content' software such as Tcpdump, Tethereal, and Snort as a packet logger. For each tool examined, a basic introduction and usage examples are given as well as extended examples which show how each tool can be used in specific scenarios. Chapter 6 discusses 'additional data analysis' tools such as tcpslice, tcpreplay, ngrep, etherape, etc. Chapter 7 gives examples and usage suggestions for tools that deal with session data and chapter 8 does the same for statistical based tools. Chapters 11 and 12 are probably much more interesting to seasoned information security professionals. Network security best practices are discussed as well as case studies that offer interesting examples of network security incidents. Chapter 13 is an excellent piece of writing that lays out the parts necessary to create a network security analyst training program. This chapters does a good job of outlining the skills necessary to help a security manager determine who should be doing what, how tools are established and used within an organization, how policies are created, and the tasks associated with each area of network security monitoring. It includes weapons and tactics, telecommunications, system administration, scripting and programming, management policy, and examples of training in action. The last two chapters, 17 and 18 will probably be two of the most interesting chapters to the casual reader. Rather than focusing solely on the security engineer, these two chapters consider the perspective of the intruder. Tools used to disrupt the integrity of network security monitoring systems are discussed as well as tactics to promote anonymity, evade detection,and affect the integrity of data collection tools. These chapters show the importance of thinking like the enemy. About the Author Richard Bejtlich is a security engineer in the Computer Forensic and Intrusion Analysis division of ManTech International. He has also worked as a consultant for Foundstone, and managed network security operations for Ball Aerospace & Technologies Corporation. He served in the Air Force Computer Emergency Response Team (AFCERT) as well as support law enforcement investigations. He is well known in the wider security community for writing papers and giving technical lectures at SANS, FIRST, Infragard, ISSA, and SHADOW conferences. He has a Bachelor of Science degree from the United States Air Force Academy, a Master's from Harvard, CISSP, and Certified Information Forensics Investigator certification. . Richard Bejtlich, a cybersecurity expert, shares deep insights on network security monitoring, highlighting continuous threat detection and the importance of logging.. Network Security Monitoring, Open Source Tools, Best Practices, Security Management. . Benjamin D. Thomas
Jan 28, 2005
•
102
risk managementsecurity analysissoftware securityInterview: Gary McGraw Discusses Software Security and Exploitation
Gary McGraw is perhaps best known for his groundbreaking work on securing software, having co-authored the classic Building Secure Software (Addison-Wesley, 2002). More recently, he has co-written with Greg Hoglund a companion volume, Exploiting Software , which details software security from the vantage point of the other side, the attacker. He has graciously agreed to share some of his insights with all of us at LinuxSecurity.com.. LinuxSecurity: Gary, please give our readers a brief introduction to your new book, Exploiting Software: How to Break Code (ISBN 0-201-786-95-8). Who does the book appeal to? Where can it be purchased? Gary McGraw: Traditionally, the field of computer security has been about network and operations people -- think network administrators and IT staff. The basic idea was to build a wall around your networks, protecting your vulnerable stuff (inside) from bad people (outside). The problem with this approach is twofold. First off, "perimeter security" is, at its essence, reactive. Secondly, there is no such thing as a well-defined "perimeter" anymore now that distributed systems are so widespread. The advent of Web services, mobile code, and Internet-based computing makes the notion of perimeter security seem quaint. Furthermore, the attackers have a distinct advantage, since they only need to find one flaw to exploit, while the defenders have to find and remove them all. In the end, the vulnerable stuff is software, and a lot of software is so buggy that it's almost impossible to protect. Because of all this, there has been an increasing interest in software security. That means one of the key questions to consider is, how do you harden software against attack? The only reasonable way to do this is to deeply understand just what attacks are. After all, how can you know that your company's critical software is secure, and that it has been built with security in mind, if you really know nothing about what the attacks on it are like? In thissense, Exploiting Software is useful to operations people, and to their management. By knowing how the software living on and making up their network is likely to be attacked, a good network admin is better equipped to manage risks. Only by understanding how easily buggy software can be compromised can CIOs begin to apply the kind of risk management that business demands to the software they rely on. Our book is also useful to software developers. It is vital that the people who build our systems (including Linux) learn to look at their software creations not just as a collection of features, but as potential targets for hackers and their nefarious exploits. It only makes sense for builders to get into the mind of their attackers so they know what they are really up against. For more information about buying a copy of Exploiting Software for yourself (and your entire development staff), check out www.exploitingsoftware.com. The publisher, Addison-Wesley Professional, also has a website too. LS: Can you offer a brief description of your background and that of your co-author, Greg Hoglund? How did you two meet or decide to co-write a book? How long have you been in the software security field? How would you say this collaboration has enriched the book? GM: First, I'll answer for myself. I am a scientist at heart, and I've been playing with computers ever since I got an Apple II+ in 1981. I studied the lucrative field of Philosophy at the University of Virginia and, inspired by the Pulitzer Prize winning book by Douglas Hofstadter Godel Escher Bach , I ended up earning a dual PhD in Computer Science and Cognitive Science from Indiana University (where Doug was my thesis advisor). Around 1985, I got interested in the 'Net. In 1993 we put up one of the first 400 nodes on the Web (Yahoo was a complete list of all websites back then). In 1995, Java came out, and being a programming languages and Web junkie, I downloaded it. Investigating itsinteresting claims of being a "secure" computing platform led to my first book, Java Security , written with Ed Felten of Princeton. After that, the need for some good work in software security became obvious. In 2001 I wrote the first book in the world on software security, called Building Secure Software with John Viega. Greg Hoglund started out as a black hat. In contrast to my academic background, he was completely self taught, and has the innate ability to think like a hacker. In fact, he wrote the first rootkit for Windows NT, and started in the process. We became friends some years ago and he agreed to co-write this book just after the publication of Building Secure Software . The idea was to look at a large corpus of attacks and exploits and see if we could discern any patterns in these attacks. Greg's expertise was absolutely critical to this undertaking, and his thinking pervades the technical aspects of the book. LS: You have previously written a book called Building Secure Software , which covered the design and implementation of secure code for the software developer. Can you explain why we might also a primer for black hats, such as Exploiting Software ? GM: Actually, Greg and I call Exploiting Software the black hat book (in contrast to BSS which is the white hat book)! Together, the two books make up the "black and white series." The reason we saw the need for the black hat book is that we strongly believe that you simply cannot build a defensible, secure system without knowing how people will attack it. The bad guys already understand software. In fact, they are software people. They know how to write code, they know what bugs to look for, and they know how to exploit them. They can hold a security patch up against a broken piece of software and use it as a roadmap for writing a new exploit. Unfortunately, on the other side of the divide, most security operations people do not understand software. They are excellent firewalland router admins, but they don't code. That's a problem. LS: What are some of the most major pitfalls that software designers fall into? Can your book help to avoid these problems? GM: In the book, we provide a set of 49 attack patterns. Attack patterns are directly related to pitfalls and problems that we see in real production software today. One of the points I like to emphasize is the difference between bugs and flaws in software. Bugs are simple mistakes in code leading to problems like buffer overflows; flaws are mistakes in design. It turns out that a lot of software is flawed. In fact, if you step back and look at a multitude of security problems over time, you'll find that about 50% of them are due to bugs and 50% due to flaws. There are too many common design failures to list exhaustively here. But here are a couple of examples... Object Oriented programming is the latest, greatest widespread coding paradigm, and it can indeed be very useful. But the distributed code model has a cost: each class (and possibly every method) is expected to do its own error handling, meaning that there is not necessarily an inherently centralized error handling mechanism. This means that it becomes difficult to determine exactly what will happen at various points of failure. Keeping track of precisely what is going on in the software as it throws exceptions willy nilly is difficult at best. Error handling is complex, and complexity is a great friend to attackers. Without some ability to manage errors in a consistent system wide fashion, it becomes nearly impossible to be sure that nothing intentionally bad could be made to happen. Then there is the more general concern that software designers tend to be a very feature-oriented crowd. They build things, and things have features. So they naturally default to thinking about security as a set of features (think SSL or access control). The problem is that security is an emergent property of a complete system. Related to this "featurism," is a related problem involving trust. Developers tend to have too much trust to their users, and do not treat user input with due suspicion. They think, "users want to access these features," instead of "attackers might abuse my system in surprising ways." These are just a few high level issues that can render software insecure. There are many, many more where these came from. LS: What practical steps can be taken out of the book, from a security analyst or administrator's point of view, to further secure their systems given that their software may be riddled with flaws? Anything beyond keeping up with their vendor's patches? GM: I hope to convince operations people to intuitively distrust software. They should be equally skeptical of the claims of security software vendors to solve all of their problem with a magic whatzit (like magic crypto fairy dust). Any security person can learn to become aware of programming languages that software is written in, and think through the security implications there. If you want secure software, you cannot just rely on (spurious) claims about security. For example, in order to 'prove' that the software is secure, a security vendor might tout their EAL level. But the Common Criterion is not a fail proof approach. In fact, it is really a "least common denominator" approach to security; because ultimately all it requires is that the vendors demonstrate specific claims that they themselves make about security, such as how well the code was protected while it was being written. But this may have no relationship to real security! That is, some of the vendor claims may not be meaningful to the consumer; and there is really no way to show that any set of claims put together somehow collectively equal "secure software" for all possible situations. This is particularly confusing for the market and its constituent consumers, because the market may not be versed in the subtleties of why various claimsmay not add up to something secure enough. It is at this point that we can circle back to the point of the book---flawed software, and how it is actually exploited. Consider that it can be quite difficult to make code secure when you insist on writing it in C. Only those who need very low level functionality should use a low-level language like C, which provides too much rope for a majority of programmers. Perhaps there should be some sort of a license for writing C! In the end, an administrator or security person should understand that programs written in C are much more likely to be insecure than those written in a modern type safe language like Java or C#. The CIO and/or top operations people can keep this in mind when they decide what software to deploy to solve a particular problem. One way for administrators to deal with software they cannot completely trust is to be very careful to not give software excessive privileges. The manner in which software is installed can make all the difference in the world from a security perspective. In fact, a bad deployment can ruin otherwise pretty darn good software! LS: How difficult is it to get started? How long would it take for today's regular non-security-focused developer or administrator to use these techniques to begin to test and improve the security of the software for which they are responsible? GM: Getting started on software security can be as quick and painless as reading some of the now available books and articles. But getting things going on a really secure footing can be a large undertaking if your organization is big. Consultants like Cigital can sometimes help with this. Of course, even without achieving excellence in software security, there is plenty of value to be found in taking the first steps, such as simply regarding software with the proper dose of suspicion and keeping privileges to the minimum necessary. LS: Your book contains an entire chapter on disassembling andreverse engineering. What is your opinion of security by obscurity? Are open systems less secure because the code is freely available, without having to be disassembled? GM: Firstly, I should say that security by obscurity simply doesn't work, with one exception. That exception is that if you carefully design a new piece of software, have it tested very carefully for security and have it extensively vetted by software security experts, and then don't publish the design, then it does work to make the software harder to exploit. So, security by obscurity only helps if the software is already rock solid. On the other hand, the "open source is more secure" debate is a red herring. All the big software houses, think Microsoft, pay entire armies of people to look at the code. In fact, the economics of the situation are on the side of the closed source guys. Analyzing code for exploitable bugs is a hard job best left to professionals who like to be paid for their work. Because they have deep pockets and can pay people to work hard on software security, Microsoft has greatly improved the security of its code in recent years. Crispin Cowan tried to set up a community-based economy for security analysis of open source called Sardonix. Unfortunately, it didn't work; mostly because there are not enough really qualified people who are interested in doing security analysis for free or for brownie points. In the end it is ridiculous to say that "all bugs are shallow." That's only true for the easy bugs. Some bugs are subtle and simply not easy to detect, even by hordes of people. A related problem...at its core, open source tends to be grown organically. Open source people are feature-oriented, and as we have already discussed, security is not a feature. However, I would like to add that open source has improved from a security perspective, probably just as much as closed source. Partially because of guys like Crispin Cowan and increased scrutiny due to recentattacks. I believe that this improvement was mostly due to the efforts of companies like IBM, and, to a lesser extent, SuSE and Red Hat rather than by some non-economic, non-subsidized means. LS: Your book mentions that black box case testing software that is touted as the final solution for software security is really no panacea. Can you expand upon this point? GM: Black box application testing solutions are not worth much money! Rudimentary dynamic testing that runs 100 canned tests and declares victory is really rather silly. How can you know if the inputs you ended up testing (especially with canned tests) are the ones that would uncover defects? It's true that this sort of testing can help determine "badness." That is if a black-box test suite finds problems, you are in very big trouble indeed. But if all tests are successfully passed, that says little about your real security posture. Don't forget that the basic problem of software security is usually at least as much one of design as of implementation. Black box tests cannot find design flaws (unless they get lucky). A much more useful idea is that of code scanning, looking at source code for potential vulnerabilities. A number of open source scanners can be found (ITS4 and flawfinder to name two), but you have to make sure you understand what the scanner is scanning for in the code. Ask yourself, are you sure that the scanning rules are right? What will they catch, and what might they miss? If you understand what they are looking for and why, code scanning can be very useful. LS: One of the chapters of your book is about the infamous buffer overflow problem. Can you briefly explain to our readers what exactly a buffer overflow is, and why it has become such an issue? GM: Buffer overflows occur because of bad language design (think C) and sloppy code. The best solution is for more software to be written with better languages, like Java and C#, instead of C or C++. Essentially,a buffer overflow happens when information is written over parts of memory that were not intended to hold that information. Think about pouring too much beer in a glass. By overwriting the parts of the memory that hold critical information such as return addresses, an attacker can get an attack payload to execute, with whatever privileges the executing program may have. We explain this in great detail in the book. Direct memory manipulation comes down to us from the days when memory was exceptionally expensive and precious, and had to be used with extreme frugality. But nowadays, there is memory to waste, and programs grab huge swaths of it and rarely release it, treating it as a raw sea of bits. Handling memory properly is something that is beyond the current understanding of many programmers, and the issue is made worse by the use of common, powerful system calls whose security implications may not be well understood by those people using them. LS: In your book, you emphasize the importance of risk analysis to overall software security. Can you please explain this concept to our readers? Why should we not aim for perfectly secure software? GM: We can't just stop using software because its not absolutely provably secure. The only way to make your computer really secure is simply to turn it off. Whenever we add functionality (or turn the machine on), we open the door to security issues. You just have to ask yourself if the functionality you want to utilize is worth the risk you take on. In many cases, the answer will be that it is, but it is critical to realize the basic fundamental nature of this tradeoff. Software security is about minimizing the risk inherent in the additional functionality that software supplies. That's why it is a risk management game. LS: What concrete improvements would you like to see in the field of software design in the future? GM: Less is more in security. Turn off unnecessary functionality and services. Thefeature-oriented set tend to think more is better, but more is less secure. Bloatware is bad. I always ask developers: who plans on having less code at the end of the year as the beginning? Very few of them say they do! Less stuff would be better. Complexity, network-based design, and extensibility (involving mobile code that does stuff on the fly and arrives arbitrarily) are the friends of the attacker. I call these the Trinity of Trouble (also covered in Exploiting Software ). When the Internet toaster is finally available, it will give an attacker the chance to burn your breakfast! LS: What are your future plans? Do you plan on writing any other books/articles? GM: When I write a book, I get to a point where I am absolutely sick of writing, and I say to myself "I'll never write another book again!" And then later, I forget the pain and do it again. I'm still somewhat in the sick of writing phase, but I'm sure I'll soon forget.. Uncover valuable perspectives on application security through our unique dialogue with Gary McGraw regarding vulnerabilities in software.. Software Security, Attack Techniques, Risk Assessment, Code Vulnerabilities, Security Practices. . Brittany Day
Jul 30, 2004
•
102
risk managementsecurity practicesapplication securityEssential Takeaways from Sean Boran's Guide to IT Security Solutions
Over the past five years, Sean Boran has put together what has become the most comprehensive online Internet security resource available. LinuxSecurity recently had an opportunity to chat with the author, talk about its new home at LinuxSecurity.com, and a few words about the resource itself. . The IT Security Cookbook contains valueable information for security professionals, computer users, and system administrators on topics including security policy development, operating system security, application security issues, and much more. LinuxSecurity.com, the community's center for security, has made available the resources within the IT Security Cookbook to its users and provided Boran Consulting with a new home, as well as email and DNS services. Sean Boran , author of the IT Security Cookbook and president of Boran Consulting explains that the resources of LinuxSecurity.com provides less expensive hosting for his free resource. Sean adds, "It also increases its exposure to Linux readers, given the pull that LinuxSecurity has." "I was already a pretty frequent visitor to LinuxSecurity.com," writes Sean, "so it seemed quite a natural place to host the cookbook, when the idea was proposed." LinuxSecurity.com: Why is it important for IT professionals to read your cookbook? Sean Boran: Because it starts at the top (policies) and goes all the way down to technical recommendations. LinuxSecurity.com: What is the intended audience? Sean Boran: Well there a general policy/classification section that is probably of interest to a large audience, where as the technical chapters on UNIX and Windows are useful to administrators of these systems. More precisely: Line managers (Chapters 1-4, 6). Computer Users (Chapters 1, 2, 6.2 User Policy) System administrators, Security administrators: Chapters 7-22 Technical Project leaders: Chapters 1-7, 15. LinuxSecurity.com: Why did you write the cookbook in the first place? Sean Boran: I didn't see anything similar on the net at the time (back in 1995/6), there was a few documents here and there, but little that pulled the various security issues together. I also wanted to make my contribution to the Internet, instead of "just taking" ... For example I use lots of free software developed by others, this was my way of "doing my bit". Security was a pretty closed affair a few years back, before SANS and all the new portals such as LinuxSecurity.com, I wanted to share ideas and allow peer review of my ideas. LinuxSecurity.com: How long has it taken to write? Sean Boran: About 1 year, with many additions/corrections over the last 5 years. Mind you like much "software" it's probably due a rewrite! LinuxSecurity.com: What does Boran Consulting do? Sean Boran: We provide IT Security and Operations services to our customers. The exact focus depends on the environment and customer needs. Last year we did a lot of work on Intrusion detection systems and audits, a few years back the focus was more on education, policy, strategies and concepts. Over the last two years many articles were written for SecurityPortal until it's demise last summer. These articles allowed me to better document and generalise tools and ideas I was using in the consulting practice. LinuxSecurity.com: What are your future plans for the reference? Sean Boran: I've been working on a series of accompanying articles on Solaris hardening, ssh and Linux. These are not yet integrated into the book, but can be reach at Sean Boran's Published Articles . I really need to review and review the book entirely, expecially the techie chapters, but am having trouble finding the time.. LinuxSecurity.com: What are some of the major pitfalls Linux administrators fall into? Sean Boran: Complacency Using default settings (though the vendors are improving a lot here) Installing too much software Notmonitoring logs Don't have policy, or have never really analysed the risk: they may be concentrating in the wrong area. LinuxSecurity.com: How can your reference solve these problems? Sean Boran: Many Linux users are techies and have a pretty good grasp of the techical issues of secuity, and sites like LinuxSecurity can keep them up to date. But a crash course on Policies and Risk management would do no harm. This book crosses many boundaries, from policy to security management to firewalls, from penetration testing to securing NFS to using encryption. LinuxSecurity.com: What do you feel is the most common Linux vulnerability? What can be done to prevent it? Sean Boran: The buffer overflow. Measures: Only install what you really need. Watch the logs of any active network daemons carefully, and chroot 'em if you can, don't run them as root if possible. Only let people access your system who really need to. Setup a regular patching schedule Pray that SW will get better... LinuxSecurity.com: Do you believe the open source nature of Linux provides a superior vehicle to making security vulnerabilities easier to spot and fix? Sean Boran: In the long run yes, but it's been painful. The basic problem is that 99% of people USE open source, but only 1% or so have to do all the work and write the stuff. I'm convinced that it's a good thing and we should all do our bit to support open source, I'd especially like to see large corporations committing programmers to key OpenSource projects. LinuxSecurity.com: Sean, thanks for taking a minute to speak with us today. . Explore core principles outlined in the IT Security Cookbook designed for both experts and end-users regarding essential protective measures and security regulations.. IT Security Cookbook, Security Guidance, Online Security Resource, System Administration, IT Security Practices. . Brittany Day
Feb 25, 2002
•
102
risk managementintrusion preventionsecurity techniquesEnhancing Security With Behavioral Intrusion Prevention Techniques
Scott Wimer, CTO Cylant Software, discusses methods for improving the security of a computer system in spite of their vulnerabilities in order to break out of the current security cycle. . The software you depend on contains security vulnerabilities. Not all of these vulnerabilities have been found yet. Some are known only to "black hat" hackers, a trump card they can play against your organization if and when they choose to. This is not alarmism. It is an honest and rational statement of the current security risk born by organizations with networked computer systems. The software running on your systems was written by people. People make mistakes. People are more prone to make mistakes when performing complicated and difficult tasks. Unfortunately, designing and writing secure software is a difficult and tedious process. As a result, the software you use contains flaws causing security vulnerabilities. Since you do not have the option of running software without vulnerabilities, the challenge is to mitigate the risks the vulnerabilities can cause. Cyclic Security Process Managing the risk created by vulnerable software is currently a cyclic process. Consequently, security is a continual cost center. Furthermore, if the process stops or breaks down, earlier gains in risk reduction are effectively lost, since an attacker only needs to find one way in. The heart of the cycle is the sequence of events below: Vulnerability, "V-19" is discovered in program "e-serve" versions 1.2 - 1.5. V-19 is publicly announced. You audit your systems for vulnerable versions of e-serve. You increase the monitoring of the systems running a vulnerable e-serve. Exploit, "r00t-19", for V-19 is released. An IDS signature to spot r00t-19 is released. You update your IDS's rule-set with the r00t-19 signature. You develop an action plan for recovery from r00t-19 attacks. Thee-serve vendor releases version 1.6, which fixes the V-19 vulnerability. But, may introduce other vulnerabilities. You upgrade e-serve on a test system to make sure that version 1.6 works properly in your environment. You deploy e-serve 1.6 on all production systems. You update your IDS rule-sets to reduce the priority of r00t-19 attacks, since they can not succeed now. Perhaps the worst aspect of the security cycle above is that you do not, and can not, control the start of the cycle. Instead, some arbitrary individual makes a discovery that kicks off the cascade of risk, cost, and work in the security cycle. Running a close second for the worst aspect of the security cycle is that even when you follow best practices, your systems are unavoidably open to attacks for large blocks of time. This is a game you can not win. There has to be a better approach. Today, vulnerability discovery dictates the risk associated with connecting systems to the Internet. The attackers constantly have the upper hand, is it any wonder that they usually win? Vulnerability Mitigation The existence of security vulnerabilities in software is an unavoidable fact. Methods for securing systems in spite of their vulnerabilities are needed in order to break out of the current security cycle. Breaking out of the security cycle requires changing the impact of software vulnerabilities. Once the impact of vulnerabilities is mitigated, effort can be directed at forward progress, instead of responding to vulnerabilities just to maintain status quo. Behavioral Intrusion Prevention A few simple observations about software form the framework of a security approach that mitigates vulnerabilities rather than responding to them. Software executes in quantifiable patterns. Software execution variation is measurable. The source of the variation can be isolated. Targeted countermeasures can be deployedagainst the source. When an attacker exploits a vulnerability in an application, they cause the application to begin executing in a different way. In fact, the PURPOSE of the exploit is to change the application's execution. If we can spot the change in execution behavior soon enough, we should be able to stop the vulnerability from being used to compromise the system. This is the rationale behind the behavioral approach to intrusion prevention. Attacks can be stopped before they inflict damage, without needing specific rules to spot each attack or attack type. Successful behavioral intrusion prevention requires meeting three challenges. First, execution observation must be able to spot changes in the execution caused by exploiting any vulnerability. Second, this observation must be made soon enough to take corrective measures before the system is compromised. Third, policies governing the responses need to be established. Security is a process, and with behavioral intrusion prevention, it is a process under your control. When your business practices change, the usage patterns of your software unsuprisingly change accordingly. New software (and upgrades of existing software) creates new execution behavior. With behavioral intrusion prevention these events require you to revisit and potentially update your policies and countermeasures. Instead of uncontrollable outside events setting off a cycle of work and risk, business decisons require the creation or modification of policies. Modifying the policies and countermeasures becomes just another step in the process of deploying software or changing business practices. Behavioral intrusion prevention stops attacks before they succeed, rather than reporting their success. If for some reason you want attacks to succeed, behavioral intrusion prevention lets you do this as well; apply passive countermeasures. In most cases though, your business is better off stopping attacks than letting themcontinue. Conclusion Signature and rule-based intrusion detection systems are not sufficient to prevent attacks from succeeding. Current IDS techniques can not deal with the inescapable fact that software contains security vulnerabilities. Behavioral intrusion prevention can help by observing and stopping attacks as soon as a vulnerability exploitation occurs. By stopping attacks this soon, the risk associated with software vulnerabilities can be mitigated. About Cylant Cylant, a division of Software Systems International, develops technologies and systems for measuring the execution behavior of running software. Cylant provides tools to observe the behavior of running software and measure that behavior against a stored behavioral baseline. . Enhance system defenses against software threats by implementing adaptive defensive strategies systematically.. Behavioral Intrusion Prevention, Software Risk Management, Security Techniques. . Brittany Day
Jan 20, 2002
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More