Security in digital products, not only in FinTech but in applications in general, is a top priority. Software development clients want to make sure that user data and business logic are safe from attacks. Users want to securely invest in applications through loyalty. Security in Amazon Web Services (AWS) is an interesting topic to view the security issue from three perspectives – the user’s, customer’s and developer’s. Let’s talk about AWS security issues and how to think about them.

Security AWS

We have to start with the most important thing – yes, AWS is secure. To the highest possible level, since the company started their cloud-based services early on and has an enormous market experience. AWS is as secure as it can be; Amazon provides the necessary expertise and resources to make it happen. AWS supports security with applications like Amazon Inspector or Amazon Web Application Firewall. 

There are, however, things you need to know before you commit to your project and go with AWS-based infrastructure.

Table of contents

AWS security certification

For a start, let’s talk about compliance. With AWS it’s a little bit easier. You need to check if the service you want to use is compatible with the Health Insurance Portability and Accountability Act (HIPAA). And it’s only the beginning. Yes, with AWS you don’t have to think about it. It provides multiple compliance controls but we need to configure the entire application to be compatible with HIPAA or  Payment Card Industry Data Security Standard (PCI-DSS). 

AWS supports security standards across the board. AWS security certification includes:

  • PCI-DSS
  • HIPAA/HITECH
  • FedRAMP
  • GDPR
  • FIPS 140-2
  • NIST 800-171

As you can see, the company is ready to help you with nearly every regulatory body there is. 

Top AWS security issues

You are giving up some control in the name of safety. For example, with Lambda, you don’t have complete control and don’t have access to patches for an operating system. This is covered by the giant. Amazon is a company that is responsible for many things and takes care of them so you don’t have to. For example, they provide server infrastructure and destroy hard drives in a special procedure that eliminates the risk of a data leak. They also have strong physical access security, so only authorized persons can be near servers and infrastructure in general. 

A fairly recent 2020 Cloud Security Report states that unauthorized cloud access is an issue for 42% of managers, while insecure interfaces give headaches to 42% of responders. 40% are worried about misconfiguration of the cloud platform itself, while account hijacking is a problem for 39%. Amazon takes care of all of that. The company secures physical infrastructure and the software development provider takes care of the rest (more on that later). 

The next issue comes from the complex nature of the cloud itself. With many different microservices that go with the cloud, control over logins and accessibility rights in general can be hard. Having a good visibility strategy is key here. You may want to think about host-based intrusion detection to increase transparency and eliminate threats.

Shared responsibility model

However, the biggest part of security in Amazon Web Services is something called a “shared responsibility model”. That means both security and compliance are shared between AWS and the customer. By reading this, we assume you are interested in managed IT service providers or another form of digital product building. If so, then the “customer” means us. As a software provider, we are responsible for some portions of the application’s security.

Here is the list of what goes where and who is responsible for what:

AWS security:

Software:

  • Computing
  • Storage
  • Database
  • Networking

Hardware / AWS global infrastructure:

  • Regions
  • Availability zones
  • Edge locations

Let’s focus on these for a second. AWS uses a concept of a Region, which is a set of physical locations where the company places data centers. Each group in this concept is called an Availability Zone (AZ). Every AZ has its own power, cooling, and physical security measures. It’s also equipped with an ultra-low-latency network for increased fault-tolerance. AZs are designed to meet high standards of security, data protection and compliance.

Also, AWS supports application’s security. We can use multi-region application architecture and prepare application for an unexpected server room failure in one country or the other. That gives uninterrupted performance.

Customer’s responsibilities:

  • Customer data
  • Platform
  • Applications
  • Identification and access management
  • Operating system
  • Network and firewall configuration
  • Client-side data encryption and data integrity authentication
  • Server-side encryption (file system and / or data)
  • Networking traffic protection (encryption, integrity, identity)

How does Code & Pepper deal with Amazon Web Services cloud security?

Let’s start with basics – we can configure the system in a way that a person has access to the system only through a certain port and with a certain protocol. 

We are also responsible for the operating system (unless it’s serverless) – installing patches and upgrading to the newest versions. We have to do database encryptions, but don’t have control over encryption keys; these are provided by Amazon. Sometimes we may want to use different and more complicated keys, but this would potentially negatively impact the application’s performance. We can always present our approach in-depth and with the use of a dedicated document. For now, let’s start with something different – the CIA golden rule for security:

  • confidentiality (only authorized parties or people can access data)
  • integrity (data can’t be improperly modified)
  • availability (authorized parties or people have access to data when they need it)

With this simple yet effective triangle, you can be sure we do everything in our power to maintain very high standards of applications’ and AWS security.

A lot has to do with Amazon Server Side Encryption (SSE) S3 service. It’s responsible for encryption on the AWS side but a software provider can encrypt key on his side as well. Especially when it comes to backups and databases – if it’s not encrypted, it’s not safe. It’s a matter of tradeoff and what your priority is as our client.

As a software provider, Code & Pepper adopted AWS as the source of serverless solutions. We went for it because AWS has multiple advantages. One is a substantial load of responsibility on the AWS side. We don’t have to secure, for example, an operating system. We can focus on delivering the application itself and install security measures where it’s necessary. For example – we think about data that goes into Lambda. In general, serverless eliminates some parts of the work (we don’t have to focus on some parts of the security and operating system) and it eliminates a lot of work. But not all. AWS gives us tools but doesn’t release us from thinking, predicting and securing.

The most important benefit for you as our client is a combined effort of an experienced cloud computing provider (AWS) and experienced software developer. Together, we can take responsibility for what we do best and complement each other.  With serverless architecture, you implement only necessary functionalities. You can do it through microservices and define security measures individually, for each of them. 

You can, for example, create architecture so that on the API gateway – firewall – Lambda – DynamoDB route we have a safe means to extract data from our database. Any potential attacks will be blocked earlier, on previous architecture layers. 

At Code & Pepper, we believe not only in performance but also in security. That’s why your application can perform and stay safe at the same time. Usually, clients come to us with an overall idea for a secure app. They tell us what compliance regulations we have to meet. Then we check what AWS services are compatible with these regulations and design the product accordingly. For example, the application can’t store the client’s whole credit number; maybe the last four digits. And even if it can store the whole number, it has to be secured with a firewall-protected key and a proper encryption. Compliance is only a beginning, but it’s a necessary step towards an overall security process. First, we do our job, implement AWS security measures, then you can safely undergo an industry-regulated audit. 

No matter the industry you’re in and the nature of your product. Sure, we can and do things like implement secure web dependencies or make sure that headers are safe and HTTPS protocol is there. We can also utilize React Native Async Storage for asynchronous, unencrypted, persistent safety measures. Security in Amazon Web Services and related services can be achieved with multiple tools. There is also the matter of a “man in the middle” attack (MITM) and DNS poofs – we can make sure that security has no holes when it comes to these types of attacks.

We can configure a firewall or even make non-standard rules. For example, if a certain IP address generates too many requests, an application rejects a connection with this IP. This is obviously DDoS protection. We can go a step further and introduce a rule that a development team doesn’t have access to the whole API schematics. Code & Pepper can also configure the AWS CloudTrail, responsible for tracking user activity within the app.

How secure is Amazon Web Services?

Very, if you know what you’re doing and are able to combine the power of tailored code with an already established cloud infrastructure. Code & Pepper offers you cloud computing services with performance and security in mind. Amazon Web Services security breach doesn’t happen directly. Hackers use exploits and system weaknesses in third-party systems, software, and procedures. A misconfigured web application firewall or rootkit enabled in the leaky part of the code can be used to bring your application down.

We do everything possible to avoid these kinds of threats. That’s why, after 15 years, we’re still on the market.