Achieving “Invisible” Security
Achieving a perfect secure state for a system is almost impossible and even when possible, my guess would be either the system is not usable or at best the system is not sustainable. For example, to limit a system from external attacks, a perfect solution would be to block access to the system from all external connections, clearly this defeats the purpose of having the system in the first place. Lowering this perfect secure state to achieve a practical secure state is still particularly challenging for a myriad of reasons. I would attempt to discuss a few of the challenges and what we can begin to do differently to push the boundary to get closer to a perfect state while not sacrificing customer experience. Starting with the challenges, here are a few that are top of mind (my biased opinion 😀)
Systems are complex, securing them will not be any easier
Systems by their nature tend to be complex and any attempt to secure them becomes a challenge. By complex, I am not referring to the type of service provided to customers/end users but in terms of different technologies and frameworks that come together to deliver the functionalities provided by the system. A good start would be understanding the different components of the system and how to address security at the component level. I am optimistic about the recent push in the industry for a standard for “Software Bill of Materials” (SBOM). An SBOM is a list of ingredients that make up software components.
Security is an emergent property, not all possible scenarios can be tested during development
The term emergent property refers to behaviors that emerge only when the parts of a system interact in a wider whole. While emergent properties can be beneficial, for example when users adapt products to support tasks that designers never intended such as using a hairdryer to get crayon marks off the walls or any home hack you have tried before. Emergent properties can also be harmful if they undermine important security requirements. An important resulting property of emergent behavior is that it cannot be predicted from simply studying the component parts. Hence, while there are attempts to address upfront as many possible security issues a system might have, there are some security issues that do not surface until the system has been put to use.
Too many security tools to choose from
Another reason why security can be challenging is that no one silver bullet exists to address all security issues, hence different security solutions have to be stacked to address security issues. This stacking of security controls is termed defense in depth. With defense in depth, multiple layers of overlapping security solutions are in place such that if one fails, the next solution step in. This overlapping approach is a challenge in itself as one has to be sure the different components are not just multiple solutions that perform the same function but solutions that are complimentary in nature.
What we should be focusing on?
In addressing the challenges, organizations are faced with implementing multiple security controls and it is quite unfortunate that a lot of the security controls are driven by a focus on attackers while the customers that the systems were designed for in the first place are being neglected. Almost every organization is undergoing some form of digital transformation to adapt to new market realities. This transformation sometimes leads to an organization changing their business model and at the heart of this transformation is changing customer expectations. Simply put, customers are a major stakeholder causing and affected by these changing business models. Any organization that does not keep up , runs the risk of rapidly losing market share and eventually cease to exist.
It begs to ask the question,
why then is the customer not the focus when designing security solutions?
If a company has invested significantly in improving customer experience, security should not hinder that experience. Ensuring security and convenience now becomes a balancing act and one should never be completely sacrificed for the other. If a system has features that becomes an hinderance, customers either stay away from using the product or circumvent the security feature if they really cannot do without the product. For instance, when password requirements become complex such as:
at least one character from at least four of these categories: Uppercase letter. Lowercase letter, Numbers and special characters
a minimum of 12 characters as well as the need to be change the password every month
no dictionary word, no repeating or sequence of digits e.g. 111 or 123
not be a similar variation of a previous password (such as changing from "Test123!" to "Test1234!")
This increases the likelihood that customers would either forget the password if not used frequently or resort to storing in unsafe locations. Another example is when the endpoint solution (e.g. antivirus) slows down system performance, end users are more prone to disable or pause the endpoint solution. Also, when a product has too many frequent security updates, some customers would either stop updating or delay the updates. To summarize what I have been trying to drive at,
the best security solution is one that your customers don’t notice.
The good news is that simple security solutions already exists, and anyone that has a smart phone has experienced this. To use your phone, you would have to pick it up (your hands) and look at it (your eyes). With little to no additional effort (except you are wearing a face mask 😷), the phone user has gone through security controls to authenticate and access the phone either via fingerprint or face recognition. This is a clear example of how security can be integrated into existing functionality without making it obvious. While some of this might have its drawbacks, the trade-off with increased customer experience is still a big win. Other examples include the use of agentless solutions for monitoring end-user device status or enabling secure access without additional software (as in the case of Google’s implementation of zero trust security). This agentless approach has the advantage of providing for quick and easy deployment for the operations team as well as no need for additional software on end user systems for a seamless experience.
While it may be ridiculous to ask for invisible security, the ask can be treated as a north star and we can continue to work to improve how security is being delivered. Though there would still be visible parts, more emphasis would now be on the consumers and not just the bad guys while thinking about security.
Some considerations that could be adopted to move towards to our north star of invisible security include:
Embed it as part of already existing functionality - Security should be embedded in functionality, just as in the case of the smart phone analogy above. Involving security teams in the planning and design phase to ensure security features are part of the use cases during development, testing and deployment. Also, security should not just be a list of added specifications. One additional consideration in involving security early in the development process is to work not just with developers but also with UI/UX experts to rethink the way in which security is designed. There should be an added objective with the goal of figuring out how security can be more subtly integrated into the overall design of the system so it is effectively hiding in plain sight.
Standardize security controls – While there are several controls to address different threats and vulnerabilities, effort should be made to collapse multiple security features into a library of well defined security processes. And where possible use already existing processes that customers are already familiar with, there is no need to re-invent the wheel. However, care must be taken to ensure that after developing standardized processes, they are codified for ease of re-use and that there is a mechanism is in place for continued improvement. For instance, several standards and tools already exist in the identity and access management space, there is usually no need to re-create this when developing a new system.
Make security integration simpler - a simpler design reduces the attack surface of a system, decreasing the potential for unanticipated system interactions, and making it easier for security engineers to comprehend and reason about the security of the system. Several security services that expose APIs to simplify integration already exist that can be leveraged to achieve this, but for this to happen organizations need to re-architect their systems to take advantage of modern practices. As discussed in the June 2021 Cloud CISO perspectives, spending billions of dollars on cybersecurity on an unmodernized IT platform is like building on sand.
In conclusion, being secure is a journey and not a destination. Security needs to happen in real time with little to no latency or friction. Balancing security and convenience is a must, though we live in a world of trade-offs where the concept of opportunity cost rules, adequate care must be taken to ensure either of security or convenience is not sacrificed for the other. Lastly, while security is still trying to adapt to changing design patterns and methodologies, there also needs to be a shift to “Customer focused security” to ensure a frictionless experience.