Discovery for Operational Security & Audits
In this second blog post on the role of discovery for security, we will focus on operational security (OpSec), that is the security activities in the phase when the product or system is in operation and use. We assume, that all supporting assets of the system have been deployed and secured as planned in the security concept and security monitoring is in place according to a operational concept.
That was also the case in March 2017 at Equifax a large, mostly American consumer credit reporting agency. What happened next, can be read in the report from the US Government Accountability Office, the famous Equifax breach. Hackers were able to access and steam personal information from millions of persons. We do not want to delve into the real scandal here, which had more to do with how the company reacted than the incident itself. Rather we would like to look at the underlying cause of the breach.
The initial compromised system was an Apache web server based on Apache Struts, a older Java web framework. The Struts development team posted a vulnerability (CVE-2017-5638) together with a fix and patch on March 6, 2017. As part of vulnerability management process, a company should get aware of such a vulnerability and identify that its asset is vulnerable. According to the ITIL incident management process, this should trigger the patch management process and and lead to either the fix being applied instantly or corresponding other measures to be taken. This was not the case as Equifax.
While the unpatched server was exposed to the Internet for months to come, hackers could exploit the vulnerability, compromise the server and attain a foothold in the environment, which finally lead to the breach of sensitive documents. This is just one famous of many cases where a server has been “forgotten” and processes, defined on paper, did not work as they should.
The basis to avoid such forgotten servers is strict IT asset management, knowing what’s deployed and what state it has. In order not to rely on documentation only, a dynamic discovery needs to be applied that find the server with its name and version, so that a vulnerability management process can detect that the system is vulnerable due to a CVE of that exact software version.
Security Monitoring and Testing
As we saw in the last blog article and video, every asset that makes part of a system or product needs to be identified in the threat & risk analysis. In the later phases the security requirements of the security concept are implemented and tested during development. At the end a security test, known as penetration test (PEN test) should proof that the security measures have been realized and provide the required security. Such security tests should also be performed when the product goes into operation. Where the status of the test could be tracked in e.g. a CMDB (see first article of the series https://blog.jdisc.com/2020/11/23/new-series-of-use-case-videos/).
Every identified asset should have some type of monitoring, which should not only include application but also security monitoring, that is, detecting an attack or incident when it happens. Servers that are not included in vulnerability management and security monitoring can be breached undetected, as we saw in the case of Equifax. Monitoring in combination with up-to-date discovery can detect that there is a old version of some software installed and create a security alert for the operations team.
The second security activity, where discovery can directly support is a security audit.
A security audit is a systematic evaluation of the security of a company’s information system by measuring how well it conforms to a set of established criteriaSearchCIO on techtarget.com
Such a systematic security audit requires again to initially determine which assets to consider in the audit and a look at many assets in a company not just a small sub-set as in a penetration test. Therefore aggregated reports and filtering is critical. Potentially also a CMDB could be helpful, altough a thorough audit on the technical level will require the detailed data model of a discovery tool. Because here the auditor will find all the details, that are required to identify out-dated software or uncompliant servers and protocols in use.
Let’s take a very basic example, just list the open ports in the environment and an auditor can identify the servers the run unsecured protocols such as FTP or HTTP without TLS. Together with a CMDB one can find out the servers and responsible persons and find the cause or make an adjustment.
Other report could check the security algorithm used for WLAN encryption or the software version of installed Apache Tomcat server:
Just open a report and a bit of filtering and a auditor can find issues.
As we saw in the NIST cybersecurity framework there comes the time, when there is an incident, that is an attack was successful and a server is compromised or even data accessed by an attacker. Now the incident response process kicks in and tries to react to the incident in a reasonable way. Usually this starts with a security analyst, that collects indicators of compromise (IoC), such as signatures of malware or suspicious activity on the network.
One way is of course, that the analyst has access to the complete environment so that he can collect all material, but often that is not the case or possible in a corporation with many departments and organizational units. In this case it can be very critical to have systems available that have up-to-date information about the servers and networks where information can be found in one place immediately. This is the case with a discovery system. The last discovery run provides up-to-date information and one can even investigate changes using the diff function as well as getting an overview quickly using maps and reports.
JDisc’s Device History Add-On keeps track of changes in your network. Create device snapshots either automatically or manually. Compare device snapshots in order to troubleshoot and diagnose change related issues within your network.https://www.jdisc.com/en/products/track-changes.html
Changes are highlighted graphically and thus easy to identify.
That is exactly what a security analyst needs, because time and accurate information are the critical points now. The analyst needs to decide quickly if immediate remediation is necessary or it is better to watch the attacker still for a while before taking measures that the attacker could notice and then disappear for some time. A discovery system as an aggregate separate source of accurate and detailed system information is a gem for the analyst.
Discovery is indeed a under-valued tool to support security in various points of the security process, from identification to the incident response. It allows security architects, PEN testers and security analysts to get the up-to-date detailed data about the managed environment in a timely manner. In combination with special-purpose security tools for vulnerability management, security monitoring and incident response, a discovery tool, such as JDisc Discovery, can make the difference when time and quality is critical.