This is the first in a series of articles about IT security. The goal is to give you an overview of topics you should consider when building or maintaining a software system with data protection requirements. The information presented in this series might also help you re-evaluate your existing software architectures from an IT security point of view. Part I highlights the importance of considering security during the whole software development lifecycle and enumerates common security goals – types of protection for the information that is processed by computer systems.
Security During the Development Lifecycle
In order to protect valuable data and ensure that your software services remain reliable, even in the face of malicious users, you have to address security concerns during all phases of a software system’s lifecycle and from the earliest stage possible.
Planning and Implementation
Addressing security from the outset often influences system designs: cryptographic algorithms increase processing power requirements, and adding security layers and functions makes architectures more complex. Consequently, you should isolate system elements that will require protection and plan for this in your design. To reduce system complexity, protect as much as needed and as little as possible. Security is a matter of details: rely on standards and best practices whenever possible. Many security issues result from common mistakes like insufficient input validation. Developers should be aware of these kinds of commonly problematic implementations and know techniques to avoid them.
Within your unit, component, or integration tests you should find out how your system reacts on failed authentication, authorization or invalid input data. Assume an attacker’s perspective and try to misuse your system. You should also perform penetration tests and regularly (and automatically, if possible) perform load tests to guarantee availability under and after heavy loads.
Deployment and Maintenance
For deployment, make sure your system is set up correctly; try to be certain that development shortcuts are removed from production and emphasize the importance of security aspects in the documentation (e.g. to keep private keys secret). Bear in mind that cryptography standards (mechanisms, protocols, algorithms or key sizes) change over time, because new modes of attack arise or existing attacks become easier to execute. Any appraisal you make of your architecture’s safety or vulnerability is provisional. Cryptographic algorithms have predicted End-of-Life dates because of ongoing research and increasing computing power. Use algorithms and key sizes that are predicted to be safe by security organizations like NIST for the lifetime of your system.
A security goal is the specification of how certain information or data flow is to be protected. Keep in mind that not every piece of data needs protection, while other data could need to be protected for more than one security goal.
Data integrity ensures that data is not manipulated when transmitting from a source through a communication channel to a destination. Common techniques to guarantee integrity are digital signatures or message authentication codes (MACs). Hash values could also be used to ensure integrity – but keep in mind that they do not prove the origin of the reference value. These techniques will be explained in more detail in a consecutive article.
Authentication is the process of confirming an attribute of a datum or entity – for example, by proving knowledge of a password. The common authentication types are proof of possession (e.g. an ID token), proof of knowledge (e.g. PIN, password, key) and proof of inherence (e.g. fingerprint, retina pattern). To increase security multiple types can be used, e.g. the combinations of two different types are also called “two-factor-authentication”. Digital signatures and MACs are often used to prove the ownership of cryptographic keys. Don’t confuse Authentication and Authorization. Authorization is the function of granting access to resources. Because in most use cases systems have to distinguish between different groups of users and grant them different access rights, authentication and authorization often are used in tandem.
Data confidentiality is provided when data is kept secret and protected against eavesdropping. This is the classic security goal that many people associate with IT security in general. In one of the next articles symmetric and asymmetric algorithms will be presented – these are techniques that can be used to ensure data confidentiality.
Non-repudiation means that a sender (the origin of data) cannot deny ownership of sent data. Imagine a contract was signed by a party and someone has to prove this to jurisdiction that it was signed by that party and no one else. To achieve non-repudiation cryptographic systems like digital signatures can be used together with a suitable system architecture.
In a security context, service availability means a system responds constantly and reliably to expected input – and delivers a defined response to unexpected input. Such a system should:
- handle valid requests up to the system’s resource limit
- handle input loads that exceed the system’s resource limit by being able to recover to a usable state after the input rate dropped again to a sustainable amount
- handle invalid requests without changing the behavior of the system and without undefined information leaking
- always operate in a safe state – in the worst case, you would have to shut down the system
Security design patterns help in designing a reliable, safe and secure system. A key to such a design is the validation of any input that enters and leaves your system. Incorrect validated inputs were a vast source of reliability and security issues in the past (think of buffer overflows and code/data injection problems).
Questions of data privacy encompass the relationship between the collection and dissemination of data, public expectations of privacy, and related legal and political issues. Data privacy rules or guidelines in a given domain may require you to:
- minimize the amount of data you collect
- explain your need for certain data
- separate different kinds of data and/or avoid cross-linkage to other databases (e.g. separate user profile information from the username and make it difficult to link them)
Even if you are not forced by any project constraints to limit the collecting and processing of data, it might make sense to do so. This reduces the system complexity and prevents data leakage – you can’t lose data that you don’t have.
The next article builds the foundation of a basic knowledge about cryptographic principles and gives definitions of common terms. Stay tuned.