architecture

You’re a software architect, or a developer who is thinking about architecture. You know application security is important but, my goodness, there is so much to it. Where do you even begin?

Here I’m going to talk about security from your perspective. I’ll discuss the important aspects of IT security that you need to worry about, and how you can get started with them. There is a wide variety of information security (InfoSec) topics, so I’ll make sure to point out which ones you will be responsible for, and which ones you just need to be aware of because someone else worries about it.

What is Application Security?

Think of application security as ensuring the confidentiality, integrity, and availability of information. This is known as the CIA triad.

Confidentiality. This means only those authorized to access the information are allowed to do so. Typically you break this down into read-only and read+write access. Anyone not allowed to access the information is denied, and the system logs this event for future analysis. Such analysis can spot trends where someone may be snooping, or bad actors looking for a weakness in your security posture. There is the principle of least privilege, which begins with denying access to everyone, then adding the specific permissions their job function requires.

Integrity. This is confidence that your data has not been tampered with. It means the information is accurate, consistent, and users can trust it. No one has accidentally or maliciously altered the data. This implies your software must function correctly, and it must ensure data cannot be intercepted and altered in transit.

Availability. The systems is readily and consistently up and running. Authorized users are able to access it, in accordance with the permissions granted to them. A denial of service attack is one way that bad actors can render your system unavailable.

Information Security is a Team Sport

You’re going to be working with other experts in your organization to establish the security strategy for your applications. Information security in general, and application security in particular, is such a broad discipline that there’s no way you can do it all alone. You need others’ perspectives and their expertise to formulate an effective application security strategy. Application security takes its input from your organization’s overall information security strategy.

As a software architect, your primary concern is securing your application and the data it manipulates. You’ll be thinking about encryption while data is in transit, and while that data is at rest. Your colleagues in network architecture will be thinking about securing firewalls, ports, etc.

Whoever is in charge of overall enterprise security – an IT security architect, IT security manager, or chief information security officer – will be your team captain. This person sets the overall IT security strategy for the organization, and helps you and your colleagues execute that strategy in your specific discipline.

Your Teammates

Number one, you’ll be working with your customers. These are the business users of your applications. Regardless of your organization’s size, they can provide guidance on the relative importance of protecting information.

Number two is your IT security people. Small to medium size organizations may have someone who is responsible for IT security. It may be their sole responsibility, or it may be one of several hats they wear. They are your key person to work with. Get to know them. Seek to understand what their overall IT security strategy is, and what are the important objectives. Have coffee with them, and meet with them on a regular basis so you can address any new developments and threats in your applications. Larger organizations will probably have an entire team dedicated to IT security.

Number three is your software teams. Your developers, analysts, QA people and DBAs have their own perspectives from which they can detect possible vulnerabilities in the products they develop. One of my teams had a developer who saw it was possible for a duly authorized healthcare provider to see information they really shouldn’t. He pointed out a provider could craft a URL to pull up information for a claim that another provider created, one they had no business seeing. He put up is hand (figuratively speaking), we talked about it, and we put in an appropriate access control long before we released the product.

Threat Modelling

This is the first step in establishing (or refining) your application architecture. Typically your IT security people lead this effort; you are a contributor. Threat modelling is where you and your team identify what your security requirements are, figure out where are you vulnerable, determine what are the consequences if bad actors exploit any of these vulnerabilities, and prepare a priority list to mitigate these vulnerabilities:

• Your organization’s industry may be subject to certain legislative and/or regulatory requirements around the data you need to protect. For example, if you handle credit card payments, the Payment Card Industry’s Data Security Standard establishes standards for protecting this data. If you’re in healthcare in the United States, HIPAA imposes security requirements you need to comply with. The GDPR in the EU and PIPEDA here in Canada dictate what you must do to protect personally-identifiable information.
• Who are these bad guys? Are they well-funded state-sponsored actors, criminal organizations, competitors, or script kiddies just out for a thrill? Or some combination of those?
• How might they be able to probe and exploit your organization? Put on the bad guys’ hat, and think of all the different ways they might gain access to your system. How you would detect such attempts?
• If they do get in, what might the impact be to your organization? Theft of confidential data? Loss of customer confidence? Breach of privacy regulations? Negative coverage in the public media?
• How can you contain whatever damage they may cause? For example, network segmentation and zero-trust security architecture are two of many ways to confine a breach to a smaller subset of your data.

Social Engineering

These days, the most common way for bad actors to get into your system is through the front door. Rather than trying to defeat firewalls, and overcome your authentication and authorization protections, they prefer social engineering tactics such as:

• Phishing emails that convince one of your staff members to open it, click on a seemingly legitimate link, which causes them to download malicious software. The bad guys are getting good at crafting these emails. The days when you could rely on poor grammar and bad spelling to detect a phishing email are pretty much gone.
• Impersonating a genuine user in a call to your help desk. The clever ones can convince the help desk analyst to reset a user’s password. Meantime, they have compromised the user’s email account, and can see the password reset email, and act on it.

Part of your organization’s mitigation strategies will be initial and on-going training on how to identify these tactics. Your IT security team will lead efforts to develop procedures for dealing with these attempts. As a software architect, you’ll need to be aware of these threats, and ensure your teams follow the mitigation strategies.

Advanced Persistent Threat

There is a theme in the InfoSec community where we assume the bad guys have already penetrated our defences. One way or another, they’ve managed to have some malicious software installed, and it is now running undetected in our infrastructure. It’s just waiting for the right moment to strike. This is known as Advanced Persistent Threat.

The trigger to strike might be a timed event, such as waiting a predetermined length of time (days, weeks or even months), long enough to assure we haven’t detected the malware. Alternately, it may be listening to its command and control centre over an Internet connection for orders to strike. Your server administrators, network architect and IT security people will have the tools and techniques that can detect this malware.

The consequences are similar to the other forms of infiltration we discussed earlier. They could be:

• Exfiltration of data – it transmits personally identifiable information, new product plans, upcoming marketing campaigns, etc. to its home world;
• Ransomware, where the malware encrypts your data, and the perpetrators demand a significant cash payment before they give you the decryption key;
• Intentional degradation of your system’s performance; or
• Any number of other very bad and potentially embarrassing outcomes.

Some of these outcomes can also lead to legal or regulatory penalties for your organization. Suffice to say, all this gives all of us plenty of incentive to protect the organization’s information.

Network Security

Using the outputs of the threat modelling effort, your network architecture colleagues will lead the effort to secure your organization’s network. As a software architect, you need only be aware this is happening. In some cases you may be a contributor, particularly when it comes to determining which network ports to open to traffic. Network architects will define and implement all the firewall rules, routing tables, and logging to control network traffic, to ensure only legitimate traffic is allowed. They’ll also provide alerting and traceability of any nefarious traffic. They’ll establish controls over who is authorized to view and make configuration changes to your network infrastructure, who can approve those changes, and who has physical access to your data centre.

Data security

You’ll be responsible for data security. Your DBAs, business and systems analysts will be key contributors. This is where you classify your data according to its sensitivity, and the risk to your organization if the bad guys obtained the data. Privacy legislation dictates a huge part of this, along with regulations specific to your industry.

Application Security

Authentication and authorization

Authentication is ensuring the person is indeed who they say they are. Once you establish that, authorization is ensuring this person has permissions to do what they are trying to do. This also extends to more fine-grained control over the specific data the person can access. Take a healthcare application as an example. One of the security constraints you may have is that a nurse can only access the chart for the patients assigned to them. If they try to access another patient’s chart, and if they’re not assigned to that patient, this constitutes a privacy breach. So it’s not enough for your application to allow someone with the role of “nurse” to access a chart. It must check to see if the nurse is authorized to access that specific chart.

Encrypted communication

Encryption between an external user’s browser and the application is essentially a requirement these days. But what about between an internal user and back-office applications? It’s a good idea, but your threat modelling effort will determine whether to adopt it.

How about between services? Is it necessary to encrypt all traffic between internal services? There is no right or wrong answer here. To a large degree, it depends on your organization’s industry-specific regulations you need to comply with. It also depends on the results of your threat modelling.

Top 10 Security Risks

Ensuring application code is secure is one of your primary responsibilities. Your best resource here is the Open Web Application Security Project (OWASP) Top 10 Application Security Risks. This is a list of the ten most common application vulnerabilities. OWASP describes each vulnerability, illustrates how the bad guys might exploit it, and provides some guidance on how you can mitigate the vulnerability. If you expose an API, they also have a companion API Security Top 10. These Top 10 guides are pure gold.

Ideally you’d want to ensure you are addressing all 10 risks in these lists. That is certainly something to work toward. However, based on my experience and my conversations with InfoSec professionals, if you can address the top three in these lists, you are much further ahead than many other organizations. That’s not to say you should stop there, but you can prioritize other work before hitting the remaining seven risks in these lists.

Defence In Depth

Use multiple layers of security to mitigate the failure of any one component. Ensure you are logging both successful and unsuccessful attempts. The idea is to make it more difficult for the bad guys to compromise your system. If they manage to break through one component or one layer of your system, they now have to hack their way through the next layer. And the layer after that, and so on. You want to make it so hard for them, they will give up and move on. Meantime, you can examine your logs to figure out how they got through the first layer or layers, and figure out how to harden them. Done right, you can make life difficult for the bad guys, while keeping a great user experience.

Keep Up With Evolving Threats

Let’s face it, staying up to date with the evolving threat landscape is much like an arms race between you and the bad guys. Gain the upper hand by subscribing to email newsletters, podcasts, YouTube channels, etc. that talk about InfoSec. Assess their impact, if any, to your organization. Have conversations with your teams and your IT security people to determine the course of action to take.

Final Thoughts

The CIA Triad informs the measures you need to take to protect your data. Threat Modelling helps you understand the consequences of a potential data breach. You are part of a team that establishes and executes the InfoSec strategy for your organization. Use multiple layers of defence. The OWASP Top 10 Guides are extraordinarily useful to help you achieve application security.