Designing for Security

Security is an important aspect of any software application. Often, it is the least priority and is overlooked while designing a system. The main focus is emphasized on functional and non-functional requirements to design our system for end users. However, there are various implicit security implications that can be evident in such systems. These security issues could lead to a system failure, system compromise, data leak, etc. In the end, this will lead to a huge customer impact, directly or indirectly.

Once the system is designed without security considerations, it becomes difficult to implement the changes once the system is in production. The cost of implementing a new change or fixing a new bug often requires architectural changes, which leads to changing the fundamentals of the software application. Oftentimes, this leads to redesign, re-release, bug fixing, etc., which is a costly affair.

Having a secure mindset during the initial design phase helps a lot in various aspects. It is always advisable to consider security as a requirement as important as functional and non-functional requirements. Various different aspects of security could be outlined for the system and, based on the priority and precedence, implemented.

Requirement Phase

Security analysis should start from the requirement phase. As a software engineer, as soon as one starts gathering functional and non-functional requirements, one should incorporate security as one of the requirement dimensions. Outlining various security aspects of the software application, dependent applications, and assumptions will ensure the design has the necessary tools, techniques, and implementation in place. Few of these requirements may be implicit, and few of them require explicit components or configurations. Depending on the application type, the security will vary. For e.g., for highly sensitive applications that deal with customer critical data, a high level of data protection is required, but for another type of application that does not deal with any critical information, another type of security will be required.

Design Phase

During the design phase, the requirements are converted into high-level and low-level details. These details will then act as a blueprint that will be used to realize a system functionally. The security requirement often pivots a system design such that it is secured from day 0. These include designing secure components, security layers or policies, etc.

Implementation Phase

The low-level design will act as a blueprint for implementing any changes. These changes will range from configuration to components. The configuration will be in the form of policies or data, which will dictate various aspects like authentication, authorization, data access, etc., to ensure safe and secure access. In order to perform these tasks, new components or implementation changes will be required. For example, In order to encrypt data at the Rest or storage layer, a configuration will be required, while in order to encrypt data at the application layer or govern the authorization based on a custom rule, a new component will be required. This component will be implemented as part of the given application or as a new application. The implementation will ensure all the security requirements are implemented and in place.

The security requirements could be:

• Ensure data encryption at the transport layer.
• Ensure data encryption at Rest.
• Ensure data encryption at the application layer.
• Ensure data access is governed by authorization.
• Ensure authorization is governed by some custom rules/policies.
• Ensure data access policy is defined with lease privilege.
• Ensure critical data is not exposed at noncritical places (storage, service, etc.)
• Ensure data deletion is implemented.

Testing Phase

Software testing is another important phase of SDLC (Software Development Life Cycle). Testing will ensure all the components are in place, implemented as requested, and no bugs are observed. There are various types of testing, such as dev testing, unit testing, integration testing, functional testing, etc. The testing should also consider security as a requirement before implementing any integration or functional testing. Once outlined as a requirement, custom test cases around security requirements will ensure proper changes are in place. For example, the integration test should contain access policy testing to ensure only properly authenticated and authorized actors will have access to the resource. This will ensure any future changes will uphold this requirement and do not break it knowingly or unknowingly.

Another type of testing is UAT (User Acceptance Testing). This will ensure the application is running as expected and required. Security should be an important factor in UAT as well to ensure a proper security mechanism is in place.

Feedback Loop

Any software application is susceptible to changes to ensure new requirements are implemented, and the application is up-to-date. In today's agile world, we see multiple deployments happening through full CI/CD pipelines. In such an agile world, the feedback loop is to ensure any change deployed is compliant and does not break any security promise. This can be achieved through automated testing, code reviews, design reviews (If any changes exist), etc.

Conclusion

Security is a very important aspect of software applications. It is the duty of a developer to ensure security requirements are considered and implemented to ensure a properly functioning and secure system. There should be a proper mechanism to test the functionality and ensure any future changes are not compromising the security of the software application. This mechanism can take place as code reviews, design reviews, documentation, testing, etc. A secure mindset will allow developers to raise the security bar of the system and uphold customer trust.