Disclaimer: This article is a personal technical study note. Any operations described should only be performed in authorized environments. Users bear full responsibility for any misuse.
Here I share my personal analysis and evaluation of several enterprise security threat modeling cases. Readers interested in enterprise security modeling are welcome to join the discussion. We should first establish the three pillars of security: confidentiality, integrity, and availability.
From the perspective of confidentiality, data must not be leaked and should therefore be stored securely; once exposed to the internet, it opens up a broad range of attack surfaces. Integrity means ensuring that content remains intact — as is the case in this article, it must have a beginning and an end. Controllability means ensuring that resources can run stably; when a user visits a website, for example, that site should be able to serve content.
| Security Attribute | Meaning | Risks | Mitigations |
|---|---|---|---|
| Confidentiality | Prevent disclosure | Data leakage, unauthorized access | Encryption, access control |
| Integrity | Prevent tampering | Data forgery, log tampering | Signatures, checksums, transactions |
| Availability | Ensure accessibility | DoS attacks, resource exhaustion | Rate limiting, redundancy / disaster recovery, WAF |
With this foundation established, we can begin planning how to carry out a security assessment, which generally proceeds in the following stages:
- Asset planning stage
- Threat modeling for assets
- Risk assessment of assets
- Determining the scope affected by the assets
- Designing a security handling plan for the assets
All of the above steps must ensure that the three security principles are upheld. Threat modeling can be performed with the STRIDE model.
| Threat Category (STRIDE) | Meaning | Typical Examples |
|---|---|---|
| S – Spoofing | Impersonating a user or system | Fake user login, forged IP address or digital certificate |
| T – Tampering | Modifying data or code | Altering database records, tampering with data in transit |
| R – Repudiation | Denying actions or operations | User denies a transaction, deletion of audit logs |
| I – Information Disclosure | Exposing sensitive information | Database leaks, logs revealing confidential data |
| D – Denial of Service (DoS) | Disrupting system availability | Overloading server with requests, resource exhaustion attacks |
| E – Elevation of Privilege | Gaining unauthorized access | Regular user exploits a vulnerability to gain admin rights |
Enterprises can either develop their own asset management system or adopt an open source enterprise management system, provided that it is built on a secure foundation. With this groundwork in place, we can begin assessing the risk landscape of the assets:
$$
Risk = Threat \times Vulnerability \times Impact
$$
A further risk assessment model can be applied here, namely the DREAD model.
| DREAD Factor | Meaning | Description / Questions to Ask |
|---|---|---|
| D – Damage Potential | Potential damage | How severe would the impact be if the vulnerability is exploited? |
| R – Reproducibility | Likelihood of reproduction | How easily can the attack be repeated? |
| E – Exploitability | Ease of exploitation | How easy is it to exploit the vulnerability? |
| A – Affected Users | Scope of impact | How many users or systems would be affected? |
| D – Discoverability | Likelihood of discovery | How easy is it for an attacker to discover the vulnerability? |
I previously created a data security exercise for several CTF competitions, and the risk assessment method it employed was based on this theory. I share it here for reference.
The exercise I created uses an assessment method that is applicable to data security, but it can equally be applied to enterprise asset evaluation. In fact, the two approaches are quite similar — as long as the assets are secured, the method holds.
Once the scope of the assets and the impact of the risks have been determined, we can begin designing security solutions for the affected assets. In practice, identifying a weakness is comparatively straightforward, whereas remediating it is considerably harder — the fix has to be delivered without taking the service offline and without degrading the user experience, and it must leave the business demonstrably more secure than before. Two approaches are available here. The first is to deploy upstream threat detection and defense systems, such as WAF, IDS, or IPS, alongside the business logic fix, so as to block potential intrusions. The second is to temporarily take certain business modules offline. When visiting some websites, for example, one may encounter a notice such as: “This service is currently unavailable due to security reasons. Please stay tuned.”
Subsequently, frameworks such as the ATT&CK matrix can be used to verify the effectiveness of vulnerability fixes and to maintain the security of enterprise systems. I will publish further articles related to ATT&CK in the future. Readers who are interested are welcome to subscribe to my RSS feed.
