DE.AE-07 says cyber threat intelligence and other contextual information are integrated into the analysis. An alert that says "unusual outbound connection" is hard to judge. The same alert tagged with "this server is internet facing, runs a library with a freshly disclosed flaw, and the destination is on a known bad list" is easy to act on. Context is what turns noise into decisions.
CSF is voluntary guidance. There is no CSF certification.
What good looks like
Detection tools and analysts get three kinds of input, all delivered securely. Threat intelligence feeds supply indicators and attacker methods. Asset inventory data says what each system is, who owns it, and how critical it is. Vulnerability disclosures from suppliers, vendors, and advisories are acquired and analyzed quickly for the technologies you run.
How to implement it
- Subscribe to a small number of trusted feeds: your cloud and software vendors, national advisories, and one or two industry sources. More feeds are not better.
- Push asset inventory data into your log platform so events show owner, environment, and criticality.
- Maintain a software bill of materials for what you ship and run, so a new disclosure can be matched to your estate in minutes.
- Use reachability analysis to see whether a disclosed flaw sits in code your application actually calls. That changes urgency a great deal.
- Define a response time for new disclosures that affect you, and track it.
- Protect the feeds and the data you share with tools, using access controls.
Try it yourself
Click through it at your own pace, or open it full screen.
You can also check a dependency manifest against known vulnerabilities for free at https://gold.safeguard.sh/scan.
A worked example
A major open source library publishes a vulnerability advisory on a Tuesday afternoon. A team with the DE.AE-07 habits asks one question: do we run it, and where? Their software bill of materials answers within minutes: two services use the library, one internal and one internet facing. Reachability analysis shows the vulnerable function is called in the internet facing service. The advisory is read, a fix is identified, and the patch ships the next morning. An alert rule for the exploit pattern is added to the log platform the same day.
A team without those habits spends the week asking engineers by chat whether anyone uses the library.
What counts as context
Context is anything that changes how an alert should be read. Asset criticality and owner. Whether the system is internet facing. The data it holds. Whether it runs software with an open advisory. Whether the source address appears on a list of known malicious infrastructure. Whether the same user is on leave. Each item reduces guesswork.
Keep sources few and trusted
It is tempting to subscribe to every feed. Resist it. A handful of sources that you read, from your own suppliers, public advisories, and one or two industry groups, provide more value than a flood nobody opens. Assign an owner, set a weekly review, and keep a log of advisories that applied to you and how fast you responded.
Share securely
Intelligence feeds and inventory data move into detection tools through integrations. Use service accounts with the minimum rights, store their keys in a secrets manager, and review access regularly. The data is useful to attackers too.
Building the habit in three steps
First, make the question answerable. Keep an inventory of systems and a software bill of materials for the applications you build or run. When an advisory appears, searching the bill of materials should take minutes.
Second, make it routine. Assign one person to read advisories from your suppliers every weekday morning, log which ones apply, and open a ticket for each. A rotating duty keeps the load light.
Third, make it visible. Report monthly how many advisories applied to you, how fast each was analyzed, and how many led to a fix. Those numbers show leadership and customers that the process works.
Common pitfalls
Teams buy an intelligence feed and attach it to a tool nobody maintains. Alerts then gain labels that nobody uses. Start with a decision: what would we do differently if we knew this? If the answer is nothing, the data is not context yet.
Evidence to collect
- List of intelligence sources and who reviews them.
- Integration settings showing inventory data in detection tools.
- Records of recent vendor disclosures and how long analysis took.
- An example alert enriched with asset and intelligence context.
Common gaps
Feeds that nobody reads. Inventory that is out of date, so context is wrong. No way to ask "do we run this library?" when a disclosure lands. Intelligence stored in a document instead of connected to tools.
Quick check
Do we need a paid threat intelligence service?
Not necessarily. Free advisories and vendor bulletins are a legitimate start. The outcome is about integrating them into analysis.
Sources
- NIST Cybersecurity Framework 2.0 (NIST CSWP 29), DE.AE-07 and its implementation examples.
