This chapter is from the book
This chapter is from the book
This chapter is from the book
Technical Implications
Technical implications refer to the potential consequences or effects of a technology-related decision or event in the cybersecurity landscape. Technical implications could involve alterations to network infrastructure, modifications to security protocols, or the need for additional server capacity following the implementation of new software or systems. It is important to ensure that you understand all technical implications of any new or existing system to ensure that you can maintain functionality and security for that system.
Allow Lists
Allow lists, or whitelists, are lists of approved inputs a user or machine can enter on a system. Using an allow list is an easy and safe way to ensure well-defined inputs such as numbers, dates, or postal codes because it allows you to clearly specify permitted values and reject everything else. With HTML5 form validation, you get predefined allow list logic in the built-in data type definitions, so if you indicate that a field contains an email address, you have ready email validation. If only a handful of values are expected, you can use regular expressions to explicitly include them on an allow list.
Using an allow list gets tricky with free-form text fields, where you need some way to allow the vast majority of available characters, potentially in many different alphabets. Unicode character categories can be useful for allowing, for example, only letters and numbers in a variety of international scripts. You should also apply normalization to ensure that all input uses the same encoding, and no invalid characters are present. An allow list needs to be continuously updated as the company works with new applications and removes old ones, and a lot of resource time is required to maintain it. We will explore allow lists in greater detail in Chapter 9, “Understanding the Purpose of Mitigation Techniques Used to Secure the Enterprise.”
Block Lists/Deny Lists
In the context of input validation, a deny list is a list of specific elements, characters, or patterns that are disallowed from being entered into a system. When approaching input validation from a security perspective, you might be tempted to implement it by simply disallowing elements that might be used in an injection attack. For example, you might try to ban apostrophes and semicolons to prevent SQL injection (SQLi), parentheses to stop malicious users from inserting a JavaScript function, or angle brackets to eliminate the risk of someone entering HTML tags. Limiting or blocking specific inputs is called block listing or deny listing, and it’s usually a bad idea because a developer can’t possibly know or anticipate all possible inputs and attack vectors. Blocklist-based validation is hard to implement and maintain and very easy for an attacker to bypass.
Let’s say you want to use deny lists despite their issues. These lists are an additional maintenance point, and you need to understand that these lists can potentially break things, and your upper layer programming should not depend on deny lists to stop attacks.
Restricted Activities
Restricted activities are specific actions or operations within a computer or network system that are limited or prohibited to maintain cybersecurity standards. These limitations are often defined through allow lists and deny lists, which, as you’ve just seen, explicitly outline what is permitted and what is not. For example, restricted activities may include accessing specific system components or downloading unapproved software.
Clearly defined restricted activities are crucial for upholding secure environments and effectively communicating IT systems’ acceptable use to internal and external stakeholders. These restrictions are commonly introduced during the employee onboarding process through key documentation like acceptable use policies (AUPs). In change management, access to critical areas like the production environment and change management software is typically restricted to authorized personnel only to ensure that only qualified individuals can make or approve changes, reducing the risk of unauthorized or harmful modifications.
Downtime
Downtime is time during which a system, network, or software application is unavailable to end users or completely offline. Downtime can be scheduled, such as during maintenance windows, as discussed earlier, or it can be unplanned, sometimes due to technical problems or even cyberattacks. Acceptable downtime might be for critical system patching or planned upgrades. A common standard of availability is 99.999%, commonly referred to as “five 9s” availability. “Two 9s” would be a system that guarantees 99% availability in a one-year period, allowing up to 1% downtime, or 3.65 days of unavailability. You might find that if you leverage third-party services, you need to ensure that their systems match, or exceed, your published service-level agreements (SLAs). You may need to implement a change if there is a misalignment between the SLA you have with your clients and what any third-party services provide to you. Unplanned downtime can disrupt business operations, negatively impact employee productivity, and potentially result in data loss. IT professionals are often focused on reducing downtime, which is crucial in cybersecurity and IT management. It’s essential to have strategies to address issues when they happen and minimize the duration and impact of unplanned downtime.
Planned downtime is needed to conduct IT maintenance activities, software installation or upgrades, and other activities requiring non-active systems. You might need to upgrade a firewall on the network, which would require turning off the current system. To prevent making the network and end users vulnerable, you would schedule downtime, typically in off-hours/non-peak time, to replace the network device.
Service Restart
In your role as an IT or security professional, one task you’ll likely encounter is a service restart, which involves halting and then reactivating a system service to implement updates, patches, or configuration changes. This process is similar to turning off a car that’s encountering a minor glitch and then restarting it.
The key aspect to note here is to understand the potential implications of a service restart, such as a momentary disruption of service. You need to ensure that potential users of the system are aware of any time impacts. You also need to thoroughly map the connections the service might have with other systems. You don’t want to restart a service connected to a critical database that could make the organization or its data vulnerable to attackers. To minimize disruption to users, it is crucial to ensure that this action occurs during a predetermined maintenance window.
Application Restart
Software application restarts are sometimes necessary procedures. An application restart is like a service restart, but it is concentrated on a specific software application. An example you’re no doubt familiar with is an app on your phone freezing and needing to be restarted to function correctly again.
Application restarts are common in IT and cybersecurity. You may often need to restart applications or systems to load patches and enforce updates. Again, communication and coordination with the stakeholders of the application are key.
Legacy Applications
In the course of your career, you will likely encounter older systems still running on a network for a variety of reasons. Handling legacy applications, which are older software programs still serving a critical function in an organization, is a typical duty you might face.
Legacy applications allow you to leverage uncommon technology, and they can be fun, especially if the original engineers are still working on the system. However, dealing with legacy applications often requires understanding older technologies and the specific nuances associated with them, which can be especially challenging if the original engineers have moved on. It is important to understand any connection the legacy application requires to function. You might find limitations in the types of operating systems the organization must maintain if the legacy application requires a certain OS to run properly.
Dependencies
When working with software components, grasping dependencies is crucial. Dependencies refer to the relationships where one software component or service relies on another to function correctly. Think of the roof on a house. The roof may be supported by large beams of wood or stone columns. If you were to remove any of the beams or columns, you would jeopardize the integrity of the roof. Understanding dependencies is critical when troubleshooting issues, managing updates, and implementing changes in the IT environment.
Services, newer applications, and legacy applications are all likely to have critical dependencies that you need to understand before you do any maintenance on them.