Ensure your organization is following best practices
Explore PlatformIf you’re new to the cybersecurity space, you may be wondering where to start, how to do it, what you need, and why you need it. In most cases, starting with the following basics can greatly reduce your overall risk.
This is the bedrock and fundamental foundation of every successful security program. Having a solid asset inventory depends on a few simple things: knowing what assets you have, where they are on your network, what software and configurations they contain, and which users and systems have access to them.
What counts as an “asset” from a security perspective? For starters, any kind of network-accessible electronic system, including (but not limited to):
If your asset inventory has gaps, your security program likely will too. If you require that all laptops have full-disk encryption enabled on them before your IT team gives them to employees – but you and your IT team don’t know about the five new laptops that your HR team just purchased using a corporate credit card – they likely won’t get encrypted (until someone finds out about it).
Network and vulnerability management solutions can help maintain and identify gaps in your organization’s asset inventory. Using a combination of network scans and endpoint agents can help provide rich, near-real-time data for your asset inventory.
Any good security program starts with multi-factor authentication (MFA) security awareness training for accessing critical personal or business data. Forms of authentication fall into three categories:
Passwords are fundamentally flawed and can be easily stolen via phishing attacks, password-guessing attacks, and malware. By simply using a password to safeguard your data, an attacker only needs to jump through one hoop to compromise your account. Requiring multiple forms of authentication for users makes gaining user credentials – and therefore access – much more difficult and expensive for attackers.
One important thing to note here is that requiring two forms of authentication from the same category will not suffice from a security perspective. For example, if you require users to enter a password and then answer a security question – such as “what’s your mother’s maiden name?” – that doesn’t count as two-factor authentication.
Since those are both “something you know,” it’s simply single factor authentication, twice. Requiring a password (something you know) and then a six-digit code generated by an app on a smartphone (something you have) does count, however.
Simply put, patch management means making sure all of your software is up to date, installed, and configured correctly. This involves obtaining, testing, and installing patches (i.e. software updates) to your organization’s systems and devices.
To do this effectively, you’ll need to continuously stay aware of available patches, determine which ones are needed on what systems, oversee their installation, and test for issues after the patch. This is typically handled as a partnership between IT and DevOps teams, as opposed to the security team.
Patch management plays closely with vulnerability management, the process of determining whether you have any vulnerabilities in your IT environment. There are three elements behind patch management: prioritizing vulnerability remediation, evaluating compensating controls (i.e. existing security techniques or systems that lower vulnerability risk), and ensuring patches are installed correctly.
Here’s why these elements matter: applying a patch will sometimes break another part of the software you’re using, causing more harm than good. Understanding this inherent risk will play a large role in how you prioritize which patches to apply.
In the event a patch does break software – requiring you to remove the patch – then having compensating controls in place will make it harder for an attacker to exploit vulnerabilities that reemerge. An example of a compensating control would be implementing firewall rules that limit the number of systems that can communicate with a not-easily-patched vulnerable system.
To help mitigate potential fallout, it’s a good idea to test patches on non-critical systems or in test environments that mirror your production environment.
Decentralization disseminates data across your networks and cloud services to ensure that if one user or server in your organization’s network is compromised, an attacker won’t necessarily have access to company data stored elsewhere.
For example, if an attacker finds a way into one of your office’s internal file-share systems in a decentralized environment, they’ll likely only be able to access that office’s shared files but not necessarily all of the files in your cloud-storage provider. However, if you have a centralized environment and an attacker compromises one server, they may find ways to easily move from that server to additional company systems and data, such as email servers, financial statements, or user directories.
Decentralization provides two benefits:
If you have a small security team, it can be incredibly difficult to monitor the dozens of cloud applications your company uses. Luckily, well-established cloud-service providers invest heavily in their own security teams and programs focused on in-depth protection of their environment.
Keeping the vendor’s application separate from the rest of your network allows your security team to focus on your organization’s core environment, while the vendor’s security team can focus on protecting the application or service they host on your behalf.
If one vendor application is compromised in a decentralized environment, that means the breach’s impact is contained to that application or vendor.
Doing this makes it more difficult – but not impossible as seen in recent breaches – for an attacker to access the rest of your systems and information. The more difficult it is for an attacker to reach a central server, the more time and money they’ll need to invest in the attack, and the more likely they are to abandon it or get caught.
This is the process of determining which of your network systems and devices need to talk to each other, and then only allowing those systems to talk to each other and nothing else.
For example, consider a nurse working on a hospital laptop. In a securely segmented network, the laptop would only be able to talk to one or two other systems, such as a print server (for printing patient records) and the patient record application itself. However, in a “flat network” – a network with no segmentation between systems – this laptop could talk to every other system on the network. If an attacker compromises that laptop, they’ll be able to attack those systems through completely unchecked lateral movement.
To segment your network effectively, it’s essential to inventory your most critical assets, understand where they sit on your network, and the specific systems and users that can access them. If the assets are accessible by more than those systems and users, that should be remedied.
To minimize a system or application’s overall attack surface, try to always grant access based on the principle of least privilege access (LPA). You’ll also need to ensure nothing on the network is able to communicate directly to your database servers, which is where critical application data is typically stored.
Once you’ve incorporated these fundamental best practices, attackers will likely find it more difficult to move freely around your network. Plus, the more expensive and time-intensive the attack, the more likely the attacker will abandon the attempt or be caught.