Your developers are plugging away, churning out code and checking off backlog items. Everything is going great and the project is surprisingly on time. But just when you thought you were approaching the finish line, you get that message from the security team you’ve been dreading:
“Hey - can I ask you about…” – Your Security Team
You know the drill – the wrong answer will mean weeks added to the project schedule to address security “concerns”. But even though you’ve prepared for this moment from the beginning with a solid design and secure best practices, you still manage to give an answer the security team doesn’t like.
So why does this keep happening?!? The problem is that you and your security team are speaking different languages.
In this six part series, we'll explain some of the common questions that security teams ask developers. We'll help you speak the language and communicate better with your security team by introducing you to some core concepts from our Application Security Knowledge Domains (ASKDs).
Part 1: Authentication & Identity
Authentication is one of the most important security controls for an application as it acts as a first line of defense for your system. Without authentication, there’s no way to know who is connecting to your application and therefore no way to enforce access control. It’s no surprise then that one of the first questions a security team will ask is:
“What are you doing for authentication?”
You’ve been preparing for this moment though. Your team did a lot of research into various authentication technologies and settled on Kerberos. You spent countless hours reading about key distribution centers and ticket granting tickets. So when your security team asked, you proudly told them “we use Kerberos!”
But then they started asking about password hashes, user provisioning (and maybe something about an identity provider?). “We need to know who’s connecting to the system” they say. You tried to mumble some answers but the security team just frowned. All that preparation for nothing! What happened?
Let’s look at this by way of analogy. Imagine that you need to find a day care for your child. You want to know who will be providing the care and what kind of credentials they have. When you ask, imagine that the potential caregiver says:
“Don’t worry, we do background checks!”
Would that make you feel good about leaving your loved one with that caregiver? Well sure, a background check is a good start – but you still need a lot more information.
The process for background checks could answer some of your questions – checking a caregiver’s credentials and criminal background, for instance. But what kind of certifications does the provider require? Are those credentials good enough? Are they expired? What about continuing education? Is this person actually taking care of my loved one or just supervising a bunch of less qualified people?
The problem with an answer like “we do background checks” or “we use Kerberos” is that it only addresses the process used to verify credentials (i.e., the authentication protocol). There are so many other things that need to be addressed. In our ASKDs, we break down a broad security control like Authentication & Identity and distill it down into the elements that are important for security. Armed with this taxonomy, you can prepare yourself for the inevitable security questions about your application. Let’s look at some of the most common questions that might come up.
“What kind of credentials are used to login?”
The most common answer to this question is “passwords” – though we’re slowly seeing a shift to “two-factor authentication”. In either case, the security team is looking for more. Just saying “we use passwords” is like our caregiver just saying “we use certifications.” The obvious question is “what kind of certifications?” A Certified Childcare Professional from the National Child Care Association means a lot more than a Child Safety Course Completion Certificate from ACME Online University.
Likewise, a 16-character, alphanumeric password combined with a U2F security key is going to mean a lot more than a 6-letter password. Even if you’re using something other than a traditional password, there’s still some kind of secret that acts as the foundation for the credentials (e.g., the private keys for a certificate, the shared secret used to generate one-time tokens). When your security team asks, you’ll want to describe the strength of those secrets (e.g., complexity requirements for passwords, key sizes for certificates).
You’ll also want to have the complete picture for your credentials, including how users obtain those credentials, if/when they expire, and how they can be changed or revoked. Keep in mind that credentials don’t have to correspond to human users – you may have other entities like machine or system users that login with credentials too. Regardless of the entities using the credentials, your security team will be interested in how credentials for those entities are managed. Once you’ve described the credentials and their management, the next question you might be faced with is about storage.
“Where are the credentials stored?”
If you’re using passwords for authentication, they need to be stored securely so that they can’t be easily stolen. Again, even if you’re using something besides a traditional password, there’s still some type of secret that will need to be stored somewhere in a credential repository of some kind. Moreover, those credentials need to be associated with the identity of a particular user so you’ll likely have an identity repository of some kind as well. The exact methods you may use will vary, but your security team wants to understand how you’re storing and protecting the secrets that make the credentials, and how they’re tied to user identities.
“Are you using SSL?”
Let’s set aside the fact that SSL is actually an insecure communication protocol (we’ll discuss the Sensitive Data Protection ASKD later in this series, but you should be using the latest version of TLS). The security team really wants to know how credentials are protected if they are transmitted over a network connection. They’re concerned about network sniffers seeing credentials as they flow from one system to another.
You may be thinking, “The communication is on an internal switched network in a restricted network zone, so why does it matter if we use SSL/TLS?” A restricted network is certainly a mitigating circumstance that reduces the risk. But security teams are still going to be interested in secure communication channels.
Think of it as a defense in depth measure – if one of the machines in that restricted zone is compromised, that machine can easily sniff the network of the restricted zone. Ultimately, what you want to do is enumerate the places where credentials are traversing the network and be ready to explain how the credentials are protected in transit (or what the mitigating controls are if they aren’t protected in transit). Your security team might still balk, but it will be a much more productive discussion!
The other thing you might be thinking is, “but credentials aren’t transmitted!” That’s where it becomes important to establish the authentication protocol you’re using upfront, which brings us back to where we started…
“What are you doing for authentication?”
Even with secure credential policy, management, storage and transmission, ultimately an authenticator needs to verify the credentials of the user. To do so, the authentication follows the process defined in your authentication protocol.
A simple application might use a rudimentary custom protocol where a username and password is transmitted to the application and compared to the one stored in your credential repository. That type of process is going to result in lots of questions about the transmission and protocol. On the other hand, some well-known authentication protocols like Kerberos don’t even transmit credentials across the network (which helps avoid the discussion about SSL/TLS entirely). Ideally your security team will be knowledgeable about common authentication protocols but even so, you should be prepared to talk about how the protocol works (especially if you’re using a non-standard or custom protocol).
We’ve talked about several parts of authentication: authentication protocols, secrets & credentials, credential repositories, credential management, and authenticators. These are some of the key pieces of an authentication security control that we break down in our Application Security Knowledge Domains.
Whether they realize it or not, these pieces are exactly the things security teams go through in their mind when they’re looking at security. By having this structured taxonomy, you can walk through the same process and be ready to speak the same security language.
In the next installment of this series, we’ll use our ASKDs and take the same taxonomic approach to answer questions about another important security area: Session Management.