Again, the OWASP has been very precise in defining the goals and motivations behind this security issue:
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.
There are many implications related to the previous definition; some of them were already mentioned in Chapter 9, Architecture, when we discussed security in the ALM and mentioned S3: Secure by Design, Secure by Default, and Secure in Deployment.
S3 relates to this topic in a way. On the one hand, the design can come from a bad initial design, which doesn't relate to the Threat Model in a proper way, so security flaws are only discovered when it's too late and when they require patches.
The second point is also crucial. Only, the functionality needed to perform the required actions should be implemented (or made visible). This is one of the first principles to apply to any system in relation to security.
With respect to the deployment, there are several considerations: perimeter security, which should be made in consensus with the development team, and everything related to configuration files and resources.
Again, the documentation recreates four possible examples of attack scenarios related to misconfiguration:
- Scenario #1: If any of the servers in production have left the admin console that's installed and the default accounts are the same, an attacker might find out those pages, log in using the default passwords, and take over the system.
- Scenario #2: The ability of directory listing should be removed from the server (or checked whether it is removed in case it's a default feature of that server). If an attacker can list files, they can find the source code and study it in order to look for flaws and gain access to the system.
- Scenario #3: Extra information related to error messages is an important source of information for any attacker: stack traces, ASP.NET yellow screens, and so on.
- Scenario #4: Sometimes during the development process, demo applications are used as proof of concept of certain features in the application. If they are not deleted, they might have security flaws.
So, when establishing a strategy for configuration, the following points should be checked according to OWASP:
- Software obsolescence: This covers all aspects involved; the operating system, the servers, database management, third-party applications, and any other resource the solution might use. (There's more about it in A9).
- Revise the Secure by default principle: Are all available features needed? In general, a review of the installed items is mandatory (privileges, accounts, ports, pages, services, and so on). This is also referred to as the principle of least privilege.
- Have you canceled the resources enabled while the development process took place? These can include accounts (and their passwords), files, demos, and so on.
- Did you change the default error pages used while developing? They can reveal informative error messages to potential attackers.
- What's the state of the security settings in TFS, IDEs, and libraries? Are they set to secure values?
For a complete set of features to keep in mind, the ASVS areas regarding Crypto, Data Protection, and SSL are helpful. However, there are some minimum measures that your sensitive data should comply with in order to be protected:
- Establish a hardening process (repeatable and automated) to make it easy and fast to deploy an application in a different environment with security in mind.
- Make sure that the process of updating software in relation to the operating system and the application itself is easy and as automated as possible. Remember to also consider libraries (proper and external).
- Think of the architecture from the beginning as a strong structure that provides a suitable separation between different components.
- You should contemplate periodical scanning and audits to help in the detection of possible flaws in the configuration (in the system or the application).
Remember all we said up until this point in relation to sensitive information, its location, and availability.
Also, remember that often, hosting applications in the cloud is an extra benefit for security since many of these operations are automatically carried on by the cloud's maintenance infrastructure.