Adopting a AAA approach to software security
Data is king. Consumers are more conscious than ever in providing organisations with accurate data. The Cambridge Analytica - Facebook scandal certainly didn’t help change consumer perceptions. With such a premium placed on data, it’s imperative that software developers vigilantly protect consumer data. This article will illustrate WorkingMouse’s approach to software security. If you’d like advice on your security strategy, contact us.
The AAA Approach
When we consider an application’s security, we keep three points top of mind - authentication, authorisation and auditing. The best strategy for security is to have a layered defence and a strong security plan in place. The strength of your security is only as strong as your weakest link and two thirds of cyber breaches are caused or enabled by employees.
As part of the layered defence, we consider the software, hardware and hosting of the applications we build.
Authentication is a way of identifying a user. Essentially, it’s ensuring you are who you say you are. Traditionally, this has been achieved through a username and a valid password. Using only strong passwords is a good start. More recently, two factor authentication and biometrics have grown in popularity. Two factor authentication (2FA) provides that extra layer of security. Not only must you provide a username and password, you will also be asked to provide a unique code, usually sent to your mobile. Chances are you’ve experienced 2FA already, especially if you’ve done any form of internet banking.
Biometric identification encrypts data until the user has been authenticated using biometric data (most commonly a fingerprint). Most smart phones now accomodate for biometric authentication.
Following on from authentication (we know who they are), a user must gain authorisation for doing certain tasks (what can they do). According to the Australian Signals Directorate, 1 of the top 4 mitigation strategies for cyber security is to restrict administrative privileges.
By using the Codebots permissions behaviour, product owners can create user groups and control access levels. This ensures that users are authorised to see only the necessary parts of the application.
Auditing is a reactive measure. It tracks resources that end-users consume. Sometimes a cyber security attack can come from a trusted source like an employee or end-user that has authentication and authorisation. So, we track every request on your application for forensic purposes and compliance with the Notifiable Data Breaches scheme.
For more depth on each of these, watch the video below or head to the Codebots blog.
Assess Your Security Measures
The AAA framework gives you a benchmark to assess your own application security. Firstly, consider authentication. Are you authenticating users with a basic username and password or have you included 2FA/biometrics. The level of authentication needed depends on the sensitivity of the data you’re protecting. Serious consideration to an extra layer of security should be given if you’re protecting any kind of financial data.
Authorisation is tied closely to authentication. Once you have authenticated a user, do they have only the necessary permissions? If you have not set permission levels or users are performing actions they should not be able to perform, a serious audit of your authorisation strategy is necessary.
Auditing requires logging of session statistics and usage information. If this is neglected, then you’re unable to effectively react to any threats. It means the same person can attack your software a number of times and you wouldn’t know. If you don’t log user records then immediate action is required to improve your software security.
There are a number of security measures you can take when hosting on the cloud. I’ll outline some of the controls we have put in place to keep applications WorkingMouse has developed, safe.
We use a multi zone redundancy plan. All critical data (database and shared file system) is replicated across at least two but more commonly three physical locations or “zones”. Because of the replication of critical data across multiple zones if a server physically fails then data that hasn’t been backed up during the nightly cycle is not lost.
Site resource access is protected using HTTPS. Internal system administration is protected using a two layer system. All databases are password protected with several levels of user privileges. Databases are only accessible from within the internal private firewalled network.
Keeping a structured approach to your software’s security is critical. Audit yourself on the three A’s and see how you perform.