Bow Tie for Cyber Security Series:
0x01 - How to Tie a Cyber Bow Tie
0x02 - Hardcore PI Coresight Hardening <-- You are here.
In my last installment, How to Tie a Cyber Bow Tie, we discussed Bow Tie methodology and how it can apply to software. As promised, in this installment, I will share an example diagram of a PI Coresight deployment. Since PI Coresight is a web application hosted in IIS, it is exposed to many of the same challenges, so I started with the enumerated threats and impacts from the web server example in the last edition. After brainstorming several barriers, I then settled on my four favorite for each threat and impact, displayed in the updated diagram below.
Barriers that were favored for effectiveness, ease of implementation and wide support of configurations. For example, one threat is "Exploit Vulnerable Product or Service", essentially the risk is that there is a vulnerability present in PI Coresight or the components it depends on and a miscreant determines a way to exploit it. Selected barriers against this include:
- Software Updates: using the latest version of the application which has the benefit of bug fixes and defenses implemented through SDL.
- Windows Server Core: provides reduced surface area to contain exploitable code. See Coresight Squared by Lubos Mlcoch for a comprehensive guide on setting up a deployment on Windows server core.
- Firewall Restrictions: a host-based firewall allows a great deal of granularity, not only limiting the accessibility to incoming threats, but also limiting outbound traffic a malicious application might use to call home for a malicious payload or communicate with a C&C server.
- Application Whitelisting: can offer significant protection since it can prevent both known and unknown malicious software from executing. For a primer on setting AppLocker rules on a PI Data Archive, see KB00994. The same concepts can be applied to other PI components such as PI Coresigh as well.
A few honorable mentions that did not make the list for this particular threat are Device Guard due to limited supported configurations presently and Antivirus as it can only protect against known threats.
Looking at the Bow Tie without any barriers in place can be daunting since there are so many ways in which disaster can strike, but hopefully this diagram with barriers in place tells a different story, showing both the breadth and depth of defenses you have at your disposal. This huge array of security options is encouraging in theory, but if you only have 24 hours in a day, where do you start? How do you prioritize which measures make it into your deployment?
A logical first step is to evaluate what is already in place. Let’s look at the type of coverage we would have after a basic installation, and for the sake of this post, I’m defining a basic installation as follows:
- Using the most recent release of PI Coresight
- Applying Windows updates
- Host based firewall is enabled allowing inbound connections to port 443
- Delegation configured for the PI Coresight web application
- Service account given documented level of access to the PI Server
In the diagram above I’ve highlighted the areas that will be covered in this basic scenario. While there is significant coverage, the first thing you may notice is that there are no barriers currently in place for the threat “Overload Server Resources”. In the previous edition, we identified four possible barriers for this particular threat:
You may also notice that there are several barriers that cover multiple threats and impacts. These are great candidates to investigate.
- IIS Role Hardening – 4 (Overload Server Resources, Unauthenticated Access, Authenticated Access, Unauthorized Access to Data)
- Application Whitelisting – 3 (Client to Another Resource, Spread Malware, Exploit Vulnerable Product/Service)
- Windows Server Core – 3 (Client to Another Resource, Administrative Access, Exploit Vulnerable Product/Service)
- Backups – 2 (Tainted Data, Manipulation of Configuration)
- Credential Theft Defenses – 2 (Administrative Access, Authenticated Access)
Given the combination of the coverage that IIS Role Hardening gives, coupled with the fact that it provides a barrier for our most exposed threat, it is probably a good measure to address first. Incidence of a barrier is just one of many factors we can consider once our options have been enumerated. If we can effectively consider the relative effort and effectiveness of each barrier, then that can further aid with prioritization as well.
Hopefully this piqued your interest! Now that we’ve drilled into a more detailed example with PI Coresight, the next installment in the series will dive into attack paths and start chaining Bow Ties together to get a closer representation of a full system deployment’s security posture, rather than an isolated component. Until next time, a few questions for discussion:
- What are some barriers you use which aren’t represented here?
- Do you see other applications for this technique that could be useful in planning or analyzing your deployment?
Update: Added links to other parts of the series.