Secure programming, the basic concepts
Security needs to be an essential tenet of your software development lifecycle from the outset.
Criminal organisations small and large see the benefit in hacking not only enterprise-scale applications and services but small business and single users. This is partly due to how difficult it can be to investigate and prosecute, but also due to the common assumption of “who would attack me?” that pre-empts the security efforts of many small operations.
The primary concern of security is protecting information in transit, processing and at rest. The primary actionable methods of security can be defined as prevention, detection and response.
Discussed in this article are some key attributes, actions, models and principles of security design. This should provide a foundation to work towards achieving secure development processes.
To clearly define your security with minimal ambiguity, it is important to understand some of the common actions and attributes which characterise security activity. When designing your software, it would be pertinent to determine which of these concepts, and to what extent, should be implemented.
In short, this is ensuring only the intended viewer may engage with the information. A secret is only a secret until it isn’t. Achieving this is dependent on authorization, and the methods to attain confidentiality are often access control for data at rest, and encryption for data in transit.
This can be a vital part of a system. Preventing unauthorized alteration of data, or proving that the data held has not been tampered with is integral to the function of some systems. This would be a commonly required attribute with data that is publicly available.
Access to a system can be a critical attribute, and as such the mechanisms of security need to enable the required availability. A system controlling railways would need to ensure greater availability than a blogging website.
These three terms are often referred to as the CIA triad and are used as a key concept of IT security. Defining the measures needed to appropriately secure your system represents the objective of security. This definition can use a balance of confidentially, integrity and availability.
The next set of actions will describe the tasks associated with security, which should be compiled with CIA to define your security elements.
This is confirming that the user is who they say they are. Failing to accurately authenticate every access attempt would allow for imposters and unidentified users to gain access. Authentication is often achieved by verifying something that the user knows (passwords), something they have (tokens/access cards) or something about them (fingerprints).
An authenticated user can be authorized to use certain services, API’s or files. The authorization mechanisms of a system provide varying levels of granular access control. This includes what can be accessed, and, how it can be interacted with. For example, users may be limited to read access only.
Auditing provides a lens for viewing the operation of the system by recording actions. It is also used as a historical record of activities. An effective log record detects and responds to actions. The responses can be predefined triggers that notify admins, potentially providing incident prevention functionality. Subsequently, the effective use of audit logs can further enhance security functionality.
In short, this is about preventing the denial of a specific action. This is only possible with effective authentication, authorization and auditing. It would be key in the planning phase to define which actions would require non-repudiation to ensure the necessary level of auditing is applied.
Throughout the software lifecycle, the combination of these attributes (CIA) and actions (auth, audit, non-repudiate), which comprise the characteristics of operational security elements, should be considered and implemented to the appropriate level.
Creating software involves many elements to combine to an overall system. Below are some of these elements and how security can be considered
Communication between elements delivered through secure channels that prevent access or manipulation is a common requirement of most applications. The Transmission Control Protocol (TCP) is a clear example. This service sequences the packets of data to prevent loss, the introduction of unauthorized packets and session hijacking.
This is about handling errors and unknown inputs. Whether the exception is triggered by a lack of response, a broken transmission or erroneous input it should be handled appropriately. The system should not fail or be compromised from errors.
A system will need a variety of configuration values ranging from initialization parameters to keys and connection strings. They must be effectively controlled to maintain the security of the system.
Security is something that must be considered carefully and implemented deliberately through architecture and planning. Having a key set of principles as the foundation will help to ensure success in this domain.
Security is not absolute, an impenetrable system does not exist. A trade-off must be made between it and other aspects of the system that represents what the system provides. A local bus timetable app wouldn’t need national-security grade encryption. It is important to reflect on the requirements of your system.
A fundamental principle that provides the user with the bare minimum access to achieve their permitted task. This can limit a system's exposure, and even reduce errors on the user part. A user with varying levels of access cannot accidentally perform a task unless they have been authorized for that action.
Defence in depth
A castle has walls, a moat, restricted access and more. Layering the security of your application in such a way with diverse methods that overlap will provide a more comprehensive solution to your application. This is something that can be applied to nearly any security function and provides great improvements.
Economy of Mechanism
Overly complex systems are hard to understand, and without comprehension, security can be difficult to implement. This also applies to the security process and tools themselves, they should be easy to understand and administer. You can further your economize by eliminating unnecessary services, thus reducing the attack surface of your system.
The system must be designed so that it cannot be circumvented. Every access attempt should be subject to the same methods, even with multiple repetitions.
Security aspects need to consider the user. If the user deems the security to be obstructive, they will often look to sidestep the security, or just not use your service. A successful design creates a transparent-to-user security mechanism.
A system is only as strong as its weakest link. Managing the security of a system requires knowing the vulnerabilities. This can also involve ensuring no single point of failure. Any failure point should be analysed, and ensure that it does not constitute a system-wide failure. This would be an appropriate time to reflect on your implementation of the CIA triad to ensure you are achieving your requirements.
Understanding the attributes, actions and principles discussed here, and keeping them as the foundation of your system lifecycle will create a strong potential for a secure system.
Models represent the systems and process that enforce security principles, whilst providing insight and explanation into the implemented security processes. There are three key elements in a system: people, processes and technology. An effective security model addresses all of these elements.
Access Control Models
Access control models can be seen commonly used in many systems, where they define what actions a user can perform. There are several different variations of this concept such as discretionary, role-based, mandatory and rule-based access control models. They invariably provide a label to an object which defines who can have what type of access, generating an Access Control List (ACL).
ACL’s can quickly become cumbersome and difficult to manage. Providing access based on a role can be an effective ACL management strategy. Users in roles such as developers, testers and managers can be given access to the objects needed to perform their roles, with minimal administration.
This is a hierarchical model, where no user can access objects with a security classification higher than theirs, known as a “no-read-up" rule. It also enforces a “no-write-down" rule, meaning that a user can only write to objects with classifications equal or higher than theirs. This is about preventing information leaks down to unauthorized users.
For some systems, integrity is more important than access. For example, stock prices. The Clark-Wilson model is an integrity-based model. The rules of the system are based on the transactions. Data can only be modified by a transformation process, which could only be executed by specific users. This data is then subject to an integrity verification process.
Use Case Models
Defining how the system processes data from expected user behaviours can represent the security requirements of a system. This would be combined with misuse cases and data flow diagrams to provide a complete understanding of the system's security aspects.
There are a wide variety of adversaries looking to attack all forms of software infrastructure and systems. These challenges can come from low skilled, unstructured hackers to highly advanced criminal organizations and even highly structured nation-state threats. The exploitation can come from within the organisation as well as from outside.
It is of great importance to consider all of the topics presented here throughout the software lifecycle, applying them proportionally to requirements to ensure the risk to your system is mitigated appropriately.
Understand the actions and attributes of security, the models used to define and understand the application of security and know the threats your system faces.
Feel free to get in touch with me on LinkedIn to discuss!