Holistic Security Primer Continued: Continuous Security

In this article we look at holistic security from an end-to-end (e2e) product lifecycle perspective in today’s world of cloud, virtualization and softwarization. This article is valid for any product development and market, be it enterprise or mobile operators. A summary is given in the figure below. E2e product development and high level security aspects is given under Solution Developer section while product procurement as well as deployment aspect is given in the section on Enterprise / Network Operator. 

Solution Developer’s coding until Enterprise/Network Operator deploy/production is related to CI/CD. It is quite interesting to see that even in this era CS or Continuous Security is not part of the usual activity. CS in place will lead us to monitoring and operations. Anyone who performs security assurance activity will tell you that even with a patch same vulnerability appears together with new ones – thus security for all steps is simply essential. 

This article together with the previous article gives a complete e2e overview of security. The previous article mainly focused on e2e security from an organizational perspective.

Solution Developer

Any product development goes from business requirements collection to the final solution that is delivered as a product. In between one will also have feature enhancements, patching activities, updates and upgrades. A brief overview of how security should be considered at each step is given below. Automation can be applied during coding, especially when it comes to testing and final solution.

• Business requirements: This is when all the requirements associated to a business are collected that will lead to the product. Security requirements relating to a given business and market should be brought in already at this stage thus linking the complete product life-cycle security with business as well. At times one might have trade-offs between security and business aspects leading to residual risks that the business owner will own.
• High-level requirements: This is the high-level product security requirement. As can be understood, security requirements associated to a product should come from this point on. Security requirements should also include identity management and monitoring aspects. Depending on the development team, already at this stage development requirements might be brought forward that again relate to security aspects.
• Solution design: Product design or architecture happens in this phase. As can be obvious, security principles and architecture must be applied to the overall design. Once again a trade-off happens between architecture and security at times that can also be related to performance or resource requirements.
• Coding: Based on earlier requirements and architecture the product coding will happen. Obviously secure coding principles are a must and should be taken care of from the very beginning. A part of secure coding in this world of “continuous – CI/CD” is also security. Security should be integrated in the coding process in the form of static and dynamic assessment. These assessments can easily be integrated and automated.
• Solution: Once everything is done the solution will be available. The solution should be tested together with all other systems around it for security vulnerabilities. At this stage all security requirements from customers and regulators should be validated. All forms of security testing should be done at this stage such as fuzzing and pentesting.

Enterprise/Network Operator

This is usually the customer side of the business. Security aspects related to the first 3 items are essentially the same, we discuss the rest below.

• Solution selection: Usually here response from solution developers is verified on paper but the same can be done using automated security testing if the solution is made available.
• Receive solution: Given that a solution is ready, the enterprise or network operator should first receive it in a lab with test environment. At this stage verification should be done whether the source can be trusted and communication should be secured. We are thus talking about authentication, authorization, integrity protection and also verification that the solution is what is expected. Such activity also brings the needs of credential management among concerned organizations. On receiving the solution the signature of the solution should be checked, i.e. integrity is not only required for the communication channel but also the solution itself.
• Test: At this stage the solution should be tested as in the solution stage of Solution Developer. In addition to that, security tests should be done as per operator’s requirements and by integrating into a test network which is a duplicate of the production network. Tests should also be done for identity management and requirements associated to monitoring, i.e. log, packet capture etc. Note that continuous tests should be performed of this replica network trying to find zero-day attacks.
• Store: The thus received solution is usually placed in secure storage. At this stage the solution should also be signed by operator credentials that can be verified at a later stage. The storage must be secure and there should be secure access control.
• Deploy/Production: When the time comes the solution will be deployed or in other words there will be build activity in production. Once the solution is securely released from storage, the signature should be verified followed by deployment. Aspects such as adequate resource availability should be checked, although obvious.
• Monitor & Operate: One additional thing that comes at this stage is management. Although all the idealistic steps for CI/CD with CS is given above, in reality one will see that different developers are given pin-holes in the security architecture to access their solutions for whatever purpose. This management part needs to be secured and brought under control using identity management and properly monitored. As said in the previous article, I think “SOC” is not the correct terminology for what a SOC usually does.