Cybersecurity is both a huge topic and a huge concern for people who provide software systems for business and consumer applications. It can be daunting when considering how much and what kinds of security are needed in support of a given system. But by following common sense principles, securing software systems is a manageable task.
A software system can consist of anything that is running software. It could be a single, air-gapped computer locked in a vault requiring biometric identification for entry. Or it could be any number of networked system nodes with public internet addresses, and published API’s (application programming interfaces) working together to fulfill the system’s mandate. The system might contain nuclear launch codes, sensitive health or financial information, or your grandmother’s blog about baking apple pie. Regardless of the scale or application, a healthy system requires some attention to software security.
Why software security is essential
Potential threats to systems exist. There are people and code actively seeking to exploit software systems for their own purposes through social and technical means. However, this is not something new and it is not something to be alarmed about. It is just the nature of things. In the same fashion as you protect your person, your home, or your business, you can protect your software systems. It is a matter of taking security measures commensurate with the thing that’s being secured and having insurance in case those measures are not sufficient.
Just as adding an alarm system to a building costs money and requires maintenance, there is an expense associated with securing a software system. The more security that is added to a system, the more it will cost in terms of the time, complexity, maintenance, and so on. The more security you add, the greater the TCO (total cost of ownership). However, if you employ the right amount of security, you maximize ROI (return on investment) by avoiding more costly security breaches. The rigor of security that is needed depends on what is being secured and is something that needs to be evaluated on a per-system basis. Nuclear codes require a rigorous approach to security—your grandma’s apple pie, not so much. Similarly, the types of security needed will depend on the system’s complexity. A system with many coordinating nodes will require more complex security measures than that of a single node system.
Start with common sense security
Regardless of the rigor and types of the security measures needed, there are common sense approaches which apply to most systems, and they start with education. Anyone that utilizes software, even if just to read email or communicate on social media, should educate themselves to be able to recognize social engineering attacks. Social engineering scams like phishing, baiting, and malware facilitate significantly more security breaches than technical exploits. Training yourself, and others where pertinent, to recognize when they are being manipulated into revealing sensitive information is an important part of any security strategy. Education surrounding technical vulnerabilities is also important, especially for software engineers and operations personnel. Technical professionals need to be aware of the vulnerabilities in the particular echo systems in which their software systems exist. This knowledge will allow them to mitigate vulnerabilities they might unknowingly expose.
Application security
After the human, the next aspect in the system to explore is the application. All but the most basic applications will have some form of application-level security. This usually takes the form of ensuring that a user is who they say they are (authentication), and granting a user access to only those features and information to which they are allowed (authorization). There are many ways to implement authentication and authorization depending on the needs of the system, some more rigorous and versatile than others. Another aspect of application level security is logging or implementing an audit trail of system events. This can keep a record of who used an application, when, and what changes they made to a system. This information can be used to diagnose security and other application-related issues. Systems that need a great deal of security should be able to look back on any change and see when it was changed and by whom. Systems that don’t need such extreme auditing can forgo the cost.
Applications don’t run in a vacuum. An application can consist of one or more coordinating nodes. If more than one, nodes will communicate with each other as part of a network of nodes. In order to secure a system, it is common to isolate networks and secure node and network boundaries. This consists of restricting communication at those boundaries to only those allowed to communicate through a respective boundary, and only via the allowed communication protocol. Keep in mind: it is important to restrict outbound as well as inbound traffic. If somehow a rogue process is initiated inside a boundary, restricting outbound traffic could prevent it from doing damage. The greater the security needs of a system, the more isolated, restrictive, and protocol-aware security measures should be.
In addition to restricting communication to only what is needed for system functionality, it is important to secure the communication itself, especially when the communication goes through public networks like the internet. System communications can carry sensitive data that could be intercepted and viewed if not encrypted. Similarly, sensitive information can be encrypted when it is saved to persistent storage to avoid anyone accessing it outside of intended channels. This includes not only system data, but logs and audit trail information as well.
Designing systems with disaster recovery in mind
Even if an appropriate level of security has been implemented in all aspects of the system, incidents can occur. This is when one relies on insurance in the form of a good DR (disaster recovery) strategy. Similar to deciding how much security is needed for a system, one needs to decide on the rigor of their DR. In this decision, one should take into account the amount of allowable downtime and its cost, and balance that with the cost of DR, including system maintenance tasks like data backups and DR testing. Even if a system has built-in redundancy, it is important to be able to recreate a system to a known good state in a predictable amount of time, and it is important to periodically test that this process works. Other maintenance tasks important to security are monitoring running software and keeping it and its dependencies up to date with the latest versions. Monitoring important system metrics can give you advanced warning of problems, security or otherwise, thereby minimizing damage. And software updates can provide security fixes to newly discovered vulnerabilities.
Using software security to maximize ROI
There is no magic bullet to be had in securing an applied software system. Each system is different and should be analyzed to determine the rigor and types of security needed. No security strategy is foolproof and it is always important to have insurance measures in place for when it is insufficient. However, by implementing common sense security measures and maintenance procedures one can ensure a healthy system that meets its uptime requirements and maximizes its return on investment.
