When requirements aren't really requirements

One of the primary roles of an architect is to develop solutions which meet business requirements.  As a cybersecurity architect, I regularly have conversations with customers about their cybersecurity needs and how we might deploy specific operational processes or technical products to match those needs.  But all too often, I find that the “requirements” aren’t really requirements at all – they’re actually solutions in their own right.  In a nutshell, many IT professionals and business leaders confuse requirements with solutions.

Here’s a great example – have you ever had someone tell you that his or her organization has a requirement to encrypt all USB drives?  I’ve heard that countless times, and often it’s followed by a lengthy discussion about the difficulties of ensuring that USB drives are encrypted, whether or not they should include or exclude removable drives, how to differentiate between personal and business USB drives, and so on.  These questions arise because the “requirement” is actually a solution – the underlying requirement is something similar to “we are required to encrypt all data in transit and at rest.”  If we return to the requirement, you realize that there are other options – for example, you can encrypt files directly, rather than attempt to encrypt the underlying medium.  Or, if the goal is not encryption but security against unauthorized access, perhaps digital rights management would be appropriate.  In this example, the proposed solution (encrypt USB drives) might not be the best way of achieving the goal (of securing data at rest), and by identifying the real requirement, you can ensure that the customer receives the best solution possible.

Whenever a customer is overly prescriptive on their requirements, or has given me other reason to believe that they haven’t thought through their requirements fully, I begin to ask very probing questions, like:

• What happens if we don’t do this?
• How could an adversary exploit non-compliance?

I also ask questions which might highlight the deficiencies of a proposed solution:

• How would an attacker work around this proposed control?
• Are there other controls which may work better than the proposed one?

This misidentification of requirements is more common than you might think.  Here are a few others I often hear – how many have you heard in the last six months?

• “We must back up our servers daily/weekly/etc.” – the requirement is actually to be able to recover in the event of a disaster.  Backup is one means of doing so; others include data replication and availability groups.
• “All connections to X server must use SSL” – the requirement is to protect data in transit.  SSL protects only a subset of connections and has itself been supplanted by TLS.  IPsec may be a better choice for internal network connections.
• “Administrators must use smart cards for logon” – the requirement is for administrators to use multi-factor authentication.  Smart cards are just one form of MFA; others include one-time tokens, phone authentication, and biometric authentication.

When you encounter these situations, drive conversations towards the true requirements and find the most effective way of achieving them.  Always strive to balance cost, time, level of effort, impact to end users (among other factors) to ensure that you discover and identify the best way to meet the actual requirement.  Your customers will benefit greatly from your diligence.

Comments

• Anonymous
  June 14, 2016
  An absolutely phenomenal article – Thank you.