How Design Impacts Security Processes
Industry professionals are painfully aware that the design stage is an integral part of a successful security build. Experience shows that it is not always possible to reengineer design and thus reconfigure the applicable data and systems to remain secure by proxy.
It seems a no-brainer that resilience to future threats is linked to optimal design. Security by design means to factor in security right at the conceptual stage. For example, if you’re planning a new developmental release for an older system, you will always need to apply new security patterns.
One step ahead in the security game
The code creation process has become much more predictable and controllable recently. Therefore, security patterns and components are more readily offered. In addition, the Cloud has allowed home-grown systems to be replaced by commodity systems, or where new solutions are being created specifically for this improved environment.
Building optimally secure apps within a suboptimal infrastructure
Security should be the first consideration before thinking of the rest. Despite product vendors being very aware of the myriad of security risks posed in today’s climate, custom development is one of the most vital areas where vulnerabilities are introduced into your technology infrastructure. However, it is not only a historical risk that one must consider. Future-proofing against further potential attacks is also key. This could involve being prepared for new connections, channels, and integrations.
Make security a part of the Enterprise Architecture conversation
Essential requirements about data, verification of authentication and by default not “trusting” other components or layers of your architecture is important to get right in any wire framing process, especially where a sign on/login process is required. Ensure core stakeholders sit at the table, so project teams make the right decisions early on. It is also helpful to create antipatterns. These include negative use cases that describe the unwanted behaviour, so it is clear what should be built, tested and iterated upon as you continue the journey. Finally, plug these insights into project management tools or a QA testing framework.
Budget allocation to drive security and design success
All this work requires budgetary allocation. Ensure a sufficient budget to cover these projects to address all nonfunctional requirements. Privacy, quality, usability and manageability are all pivotal criteria to measure.
Security-by-design starts when a development team publicly airs that there are circumstances when suboptimal events can offer from apparently optimal software. From that admission, you will see that design involves satisfying a combination of functional requirements, nonfunctional, and assurance (or risk avoidance) requirements.
Given three conditions (one from each category), you need to know how stakeholders and end-users would prioritise the requirements mentioned above. Historically, the priority might be ranked as function (productivity-oriented), nonfunctional (look and feel oriented) and assurance (especially if it affects productivity or look and feel of the interface). Is your approach the same today?