IT managers, software engineers, and infrastructure engineers should always be aware of defensive security best practices. These are practices usually learned in college, in structured training, vendor training, certification exams, or (in the worst-case scenario) on-the-job experience. Vendors of technologies, such as software development platforms, operating systems, and switches will usually build in specific security features to defend against specific types of attacks. So, it’s important to learn about how to properly implement and configure those security features. Unfortunately, software developers and IT staff often learn from free online videos. So, they may not be aware of the defensive security best practices that apply to the technologies they build.
Offensive vs. Defensive Security
In the security world, two different types of security paradigms exist. Offensive security professionals perform a security analysis by trying to detect vulnerabilities. For example, using penetration testing (a.k.a., pen testing) to discover open ports that expose vulnerable systems to the internet, which malicious hackers could exploit for exfiltration or ransomware attacks. Security professionals may also perform social engineering exercises, phishing simulations, website assessments, and review other attack vectors. Defensive security attempts to prevent attacks by reducing the attack surface and configuring software and systems so they are not easily exploited. Security professionals may also advise on defensive security. However, defensive security should be part of standard training for all IT professionals, independent of whether they build software or systems.
How to Ensure Strong Defenses
Education is always the best first line of defense when trying to ensure that IT systems are well defended. The more IT managers and staff know about technology and how to defend it, the better off the organization will be. And nothing beats the vendors own documentation and security recommendations concerning what technologies to use and how to properly implement or configure them. Those systems could be websites, switches, devices, hosts, and other systems. This is something that many junior-level and mid-level “professionals” unfortunately skip as they dive straight into desperately building a working solution. And non-technical IT managers would never be the wiser.
Because technologies, and the threat landscape, are constantly changing, this makes information technology a challenging career. The IT manager and workers always have to be on-guard and look out for changes to the threat landscape. This requires them to continue learning about the technologies, listen to the news and professional channels, and learn about changes to technologies as they are released. This also requires a lot of awareness and support from the IT manager.
Security Audits & Threat Assessments
IT managers should initiate a regular security audit on the department’s different types of systems, including websites, databases, switches, document stores, threats to intellectual property or customer data to understand where they may need to reinforce security. The IT manager doesn’t have to be a security analyst. However, the IT manager should know who to ask, and what information to ask, to secure the department. And ideally, IT managers should have checks in place to ensure their IT staff is implementing or sufficiently configuring security.
Software Design
Software developers, starting at a junior-level, need to be minimally versed in common security practices. Common ones include parameterizing database queries to prevent SQL injection attacks. Encrypting passwords and communication over the internet with SSL certificates. Create a repository of libraries or tools for developers to avoid accidentally downloading those resources from untrusted sources.
Service endpoints should implement token handling, such as OAuth or JWT to lock-down endpoints so only authenticated and authorized users may retrieve data from those endpoints. Use access keys for inter-service calls. Don’t put passwords and connections strings in configuration files that are committed to the source control system. And implement Cross-Origin Resource Sharing (CORS) to prevent unauthorized access to endpoints. Also, create strict policies and procedures, and do a regular audit, to avoid accidentally exposing internal resources to the public.
Software Management
Keep internal software and systems up-to-date with the latest updates. And use software deployment services (e.g., Windows Server Update Services (WSUS)) to deploy updates at specific times, and to specific machines, to prevent the possibility of compatibility issues. Software and systems vendors will release security fixes if they discover vulnerabilities. And it’s important to apply those updates so vulnerable systems are not exploited by malicious hackers.
Audit installed software and uninstall any unnecessary or unauthorized software, or software that does not come from trusted sources. Keep internal copies of approved software installed on systems so users are not installing that same software from untrusted sources. In addition to creating a list of authorized software, create an “allow list” (using a web-filter) to only allow users to download software from approved sites.
Lock down any software that could be used for remote access, ports of entry, email (using spam filters), and web browsers (using web filters).
Device Management
Lockdown devices and host computers by following the principle of least privilege. In other words, only allow users to access the resources they need and nothing more. Sometimes, IT staff or system administrators will unwittingly sign-in to host computers using elevated privileges to install software, without removing their cached credentials afterwards, which may introduce security concerns. Or they will give a user or computer account more privileges than is necessary.
Close open or unused ports on operating system software firewalls to prevent malicious hackers from “pivoting” between systems using stolen cached credentials. This is how ransomware attackers gain access to an entire network. Configure user and group accounts to only allow access to specific approved resources. And disable unused features or removable media that could be used as a port of entry by malicious hackers.
Networks could be segmented (e.g., using subnets or ideally virtual local area networks (VLANs)) to prevent communication between departments. An example would be isolating the development department, or the executives, from the rest of the network so other users or malicious hackers are not able to gain unauthorized access to those networks. This may also prevent malicious hackers from stealing password hashes to gain access to other host systems on the network for the purpose of exfiltration or ransomware attacks.
Make certain users are storing credentials using an encrypted password manager. In some places, such as online password managers, use multifactor authentication (MFA). The systems administrator may be able to configure computers on the network (e.g., using Group Policy) to prevent those hosts from caching credentials, which would present security concerns. And don’t put passwords in plaintext files, such as FTP, SSH, Bash, Powershell scripts, or configuration files. Software could be used to execute scripts securely.
Lastly, try to detect and prevent intrusions using server logs, switch logs, or monitoring software to detect unauthorized access. And regularly update antivirus software.
Disaster Recovery
IT managers need to have a way to fully recover all their files and systems in the event of a catastrophic failure. Unfortunately, many fail to put adequate systems in place, or fail to test those systems, which leaves the IT department vulnerable to attacks and data loss. So, it’s important to have good file-level backups, volume backups, perhaps offsite backups, or a data recovery site, which could also be hosted in the cloud. Many systems administrators fail to do that because they never learn how to properly backup their systems.
Additional Resources