Application Security Achitecture Assessment
What is Application?
In simple terms, application can be defined as a program or group of programs that can help a user to complete specific tasks. Some examples of applications are: MS Word, Email, Google maps, etc. Also, applications can come in different flavors as provided below depending on the platforms they are hosted on:
- Desktop Applications
- Web Applications
- Mobile Applications
- Cloud based Applications
- Mainframe Applications
Each different type of application serves a unique purpose. But it goes without saying that every comfort comes with its price, and application is no different. They are just like a double-edged sword. Well, the swords are still better because we can at least perceive edges that can mistreat us, however that’s not the case with applications – especially for normal users who are not aware of the ramifications about misuse of information, if compromised by malicious users. So it is really important to protect sensitive information stored on your systems or database from unauthorized access (E.g. Trade Secret, Credit Card information, Personal Information, etc.).
Question again? I know what you would think now. How would an organization be able to categorize data that is considered sensitive and protect it with more stringent controls than public information, right? That is where – Information Classification or Data Classification comes into picture. But let’s leave this topic of Data Classification here for post on some other day. For now, the important to remember – more sensitive the data, more rigorous the controls!
Furthermore, each application hosted on a different platform has a separate set of risks, and understandably the security controls required to protect the data hosted on each of them will differ accordingly. Now you have high level understanding of what the application is, and what platforms are they usually hosted on, let’s dive into a bit more detail around what an organization should focus on to secure the architecture of an application. We will limit the scope of this post to only review the checklist for securing an Architecture of a Web Application.
The section below summarizes areas any organization must take into consideration while conducting risk assessment for an application either developed in house or a third party vendor before it goes live:
- Data Sensitivity
- What is the highest level of sensitive data handled by the application according to data classification policy of an organization?
- Authentication
End User Authentication
- How are the users authenticated to the application?
- If Username / Password –
- What is the password complexity and rotation policy?
- Are passwords stored hashed and salted in a database? What hashing algorithm is used?
- If users are authenticated through Single Sign on (SSO) – who will be the Identity Provider and the Service Provider? How will it be configured? (E.g. SAML, OAuth2, OpenID Connect, etc.).
- If Username / Password –
Inter tier (System to System) Authentication
- If the application in question is a multi-tier application, how is the application server authenticating with the database server?
- If Username / Password is used –
- Is the password stored and encrypted on application server in a configuration file or stored in plain text? Is the password hashed and stored in the database server?
- What is the password complexity and rotation policy? Who manages the passwords and how is the access restricted from unauthorized access?
- If mutual certificates are used –
- Are certificates self-signed or signed by a Certificate Authority (CA)?How often are the certificates rotated?
- If Username / Password is used –
- Authorization
- What user roles are supported by the application?
- Can the access provision be in compliance with principle of least privilege?
- What is the provisioning and de-provisioning process for users to be on boarded to and off boarded from the application?
- Are user entitlements reviewed on a regular basis to make sure only authorized users have access to the application?
- Audit / Logging
- What user actions and system events are logged by the application?
- Is there any sensitive information being logged by the application? For e.g. user credentials, SINs (Social Insurance Numbers), SSNs (Social Security Numbers), etc.
- Where are the logs stored?
- Who has access to those log files and how is it restricted from unauthorized access?
- Will the access and edits to those log files be logged?
- Are the logs forwarded to any event monitoring tools like Splunk, QRadar, etc. for further investigation during security incidents?
- If logs are stored outside the firm’s infrastructure, will they be provided back to the organization per request for investigation purposes?
- Input Validation
- Does the application have any input validation mechanism in place to validate inputs provided by the user from the UI (User Interface)? (E.g. Blacklisting, White listing, Business Rule Validation).
- Does the application allow users to upload files from the user interface? If so, is there any file type validation in place to restrict users from uploading malicious files?
- Are the files scanned through antivirus solutions before storing them to the database?
- Does the application allow users to download files from the user interface? If so, is the user access restricted to the firm’s infrastructure to protect sensitive data from unauthorized disclosure?
- Does the application provide any protection against injection attacks by using stored procedures or parametrized queries while storing data to the database?
- Does the application perform output encoding to protect against Cross Site Scripting (XSS) before passing the data back to the client browser?
- Session Management
- What is the inactive session timeout for the application?
- Are sessions generated using the random session ID generators?
- Does the application allow concurrent logins?
- Are the cookies set to httpOnly and Secure?
- External Data Transfer / Batch Jobs
- Does the application provide data to any other entities outside the firm’s perimeter? If so, is it done over an encrypted channel?
- Is the connection from the user’s system to the application encrypted through TLS 1.1 or above?
- Does the application processes any batch jobs? If so, is there any data purging policy in place to make sure data from the temporary folders is deleted if the access is no more required?
- Data at Rest
- Where is the data hosted? Internal or External to the firm?
- Is the firm data logically or physically segregated from other client’s data at the vendor premise (in case application is hosted outside the firm)?
- How is the access to the database restricted to make sure only authorized users have access to firm’s data?
- Is the data at rest encrypted? If so, which encryption algorithm is used? And last but not the least,
- Who manages the keys and how often are they rotated?
How about we stop here and ask you a question – Have you ever considered before, a thought of securing the architecture of an application? If the answer is no, you have got the food for thought now. There are many areas that need to be focused on while securing the data handled by the application and we will try to go through them as we proceed further with other posts on this blog. Go back, and make sure you have right controls in place for the applications you are using in your organization.
Keywords: Information Security, Application Security, Security Architecture, Risk Assessment
Thank you so much guys for taking the time to read this post. Please let us know how we did and make sure you: LIKE, SHARE, SUBSCRIBE, and COMMENT.
Your feedback will be highly appreciated and feel free to let us know about any requests you have regarding the topics we should include in our upcoming posts. We will be more than happy to prioritize and accommodate your requests!
1,564 comments found