security controls

During the green room chat before our first podcast episode, Rachelle Loyear and I began discussing “Design Thinking”. My personal experience was limited to a one day workshop with IBM a couple years back, but as you can hear in the podcast this is an area Rachelle has spent a lot of time exploring. Over the years I have worked with many high quality security products and for the most part the user experience,(UX), almost always felt like an after thought. This is not a slight against the companies that work very hard to bring us these products, and as techies we tend to want large volumes of information and lots of buttons on every screen but a recent personal experience has given me real cause for reflection on UX design, even for security tools.

The basic understanding of “Design Thinking” is best summed up in a quote from IDEO, the company that brought many of the current practices in this methodology forward over the last two decades.

“Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.” Tim Brown, Executive Chair of IDEO

Do read Tim Brown’s books for the full understanding but essentially a good design will be desirable from a human perspective, technologically feasible and economically viable for the company. While most people think of products as design candidates, software applications have certainly adopted this focus on UX and a similar design thinking approach can be applied to services as discussed in “This is Service Design Thinking” by Marc Stickdorn

Venn diagram showing the intersection of FEASIBILITY
DESIRABILITY and VIABILITY

The “3I” model of “Inspiration, Ideation and implementation” was developed by IDEO 20 years ago and the definitions below are a bit of a composite of the various interpretations offered by different service providers.

Inspiration: Identifying the problem or opportunity that warrants a solution, primarily through considering the actual user of the product or service and the challenges they are facing with current offerings.

Ideation: This goes deeper than just brainstorming, promising ideas are further assessed with a multi-disciplinary team to develop fleshed out conceptual solutions, the best candidates can then be turned into testable prototypes.

Implementation: Prototypes are developed and tested with users, user feedback drives updated prototypes until finally moving from prototype to amarket place offering

The main premise behind design thinking is an interdisciplinary group working on a problem at the outset will develop new solutions that are more innovative and more likely to succeed than traditional R&D models. The challenge to companies more comfortable with the engineering followed by design approach is there is no one best way to move through the process and it may appear chaotic at times but the approach is much more mainstream now than when IDEO first started two decades ago. How we can help as security practitioners is to work within our organizations to ensure we are part of that interdisciplinary team when we hear terms like “design thinking” and “agile” associated with new projects. Without security specialists involved in these design and delivery activities the trend of last minute addon compromises is likely to continue.

To move this conversation from the academic to real life one could start with a review of Tim Brown’s short blog post on Empathy, which is one of the inputs into the inspiration phase listed above. Putting yourself in the position of the person interacting with a product or service. The empathy concept became very real recently when my partner, a physical therapy student, was required to spend 24 hours without the use of her dominant arm and perform day to day activities. Where feasible I supported by also forgoing the use of my right arm which made the challenges of modern computer security controls immediately obvious.

Long complex passwords are potentially impossible to type if a person has dexterity limits, for example try reaching shift/4 with two fingers to input the $ sign as a special character. The all to common “Ch@ngeMeN0w!” could be a very unpleasant onboarding password for a new employee or student. More critical accounts and remote access now typically require a secondary code from a smart phone app. Even with two hands I have struggled from time to time with responding quickly enough to Microsoft Authenticator validation requests.

Creating more inclusive, accessible work places and public services isn’t just a nice thing to do, it is actually a law in many countries within the world. No one at Caffeinated Risk is a lawyer but researching did uncover an interesting clause in the Americans with Disabilities Act of 1990, which does specify the need for information technology systems to be accessible through multiple means.

“An accessible information technology system is one that can be operated in a variety of ways and does not rely on a single sense or ability of the user. This is important because a system that provides output only in visual format may not be accessible to people who are blind or have low vision, and a system that provides information only in audio format may not be accessible to people who are deaf or hard of hearing. Some individuals with disabilities may also need accessibility-related software or peripheral devices in order to use systems that comply with Section 508.”

Section 508 mentioned in the text above is part of the Rehabilitation Act of 1973 and deals specifically with electronic information and technology. While governments may have been thinking data stored in electronic systems needed to be protected back in 1973, in 2021 there isn’t an enterprise any where that isn’t faced with that same requirement. To that end, we have created numerous information security policies which will include at least one policy on access control with passwords and MFA likely to be the defined requirements. Most password policies with also include very specific requirements pertaining to complexity and password length, account lock out thresholds and so forth.

It may be true that certain password complexity requirements and MFA solutions do not consider accessibility the need for securing access to electronic systems does not disappear. Although alternatives mechanisms such as biometrics are now commercially viable since they are included on both mobile devices as well as modern laptops availability does not always equal usability.

In Praise of Design Thinking:

Without participating the 24 hour exercise I am not sure I would have fully considered the impact many of our security controls might have on accessibility. Password logins are only one challenge, secure areas may not have badge readers at a practical height for someone in a wheel chair, the same could be said for key pads and pin based door locks. A number of ideas are already coming to mind on how we could solve some of these challenges but it will take experts in software interfaces, operating systems, physical design and policy creators to resolve these issues.

A quick search for accessibility features will show commercial operating systems like Windows do have a number of options for allow disabled people to interact with the operating system itself. I suspect the challenge will reside more with the applications running on top. For example, how many building access applications could make a similar claim? Full disclosure, I have not looked, so it would be great to identify any such offerings in the market and review how they met the design challenges.

As a call to action for our readers please feel free to comment on these three points to ponder. Depending on interest this may lead to more of this research and perhaps even a podcast guest with deep domain knowledge in this area.

How many organizations have provisions within their current information security policies to permit user authentication via methods other than passwords and token/time based multifactor authentication?

How many organizations have deployed a technology stack within their company that would facilitate secure access to enterprise resources without the use of a password?

How many organizations are now including accessibility features as requirements in their technology investments?

While I personally consider packet captures and memory dumps more interesting than policy and standards documents, I have been on many professional engagements over the years where the root contributor to the chaos was a lack of clear direction, either because solid governance was missing for one reason or another. Decades into my career now, I view these as important parts of a sustainable information security program.

Unfortunately, policies and standards are not something one can download from the SANS or ISACA website, make a few changes and call it a day. I often joke, the only thing worse than having to read policies and standards is writing them. The operating constraints of the organization are can never be fully understood by the policy writers and these documents are meant to provide long standing direction many years past the date of authoring. In all fairness to those authors, (myself included on some occasions), there is an assumption those responsible for implementing the controls understand the intent and make intelligent adjustments when needed because thing can change quickly in unpredictable ways.

When the world turned upside down overnight with the pandemic quarantine most companies found their remote access solutions were running at full capacity yet usability was not there. My first office VPN solution was PCAnywhere over a dial up modem, when I compiled the PPTP patch into my RedHat kernel and connected via cable modem 300kbs felt like a rocket. This memory lane visit shows remote access is old and so is the security guidance around it. It has been well entrenched in the remote access policies of many companies that while connected to the organization’s VPN all traffic from the remote computer needs to be contained within that encrypted tunnel. This of course includes all traffic to the internet because the common believe was the company needs to monitor what it’s people are doing when connected to the internet.

Back in 2000 something, when most company services were internal and internet access was not even granted to every worker, avoiding split tunneling made sense. That road warrior connection from the hotel room should not be exposing the internal corporate network in anyway. Fast forward to SaaS based email and CRM being the norm, the mass migration to home offices meant most companies suddenly found themselves burning double the bandwidth overnight. Once to bring the worker in, then direct their request out to Office 365 or SAP in the cloud, bring all that data back, then send it out once more to the home office. In addition the the double tax on the bandwidth, the requirement for monitoring the user activity isn’t being fully realized either because the traffic is encrypted from the worker’s desktop right to the SaaS service. The state of the art firewall knows it’s TLS traffic and the source IP is assigned to someone inside the company but that is about it. Conversely, the SaaS provider knows exactly who it is because they authenticated both the worker and are decrypting the TLS communications.

Those that clung tightly to a policy statement like “VPN connections shall not permit split tunneling”, likely found themselves trying to block high bandwidth content requests at perimeter firewalls. Those that realized a service like Office 365 is secured at the transport layer and the authentication layer, ( just like a VPN connection), may have found a policy change that permitted trusted connections to take the least expensive route allowed work to get done and the firewall whack-a-mole game never even got started.

If there is a call to action here, it would be review the policies that are in place and consider what threat or threats were intended to be mitigated? Does the current language make that abundantly clear to the reader five years from now dealing with a situation no one would have predicted?

Caffeinated Risk

Design Thinking & Security Controls

Is the cure worse than the disease?