OpenCyber AcademyLearning outcomes
You will (1) describe the services a college runs and how they connect; (2) mark which services are internet-facing; (3) find where each service keeps logs; (4) explain why architecture knowledge makes intelligence usable.
1.1 College services
Ashgrove College runs a learning platform used by 6,000 students, staff and student email, a library catalogue, a finance system, a student-records database, Wi-Fi for campus visitors and a website. Some are hosted on campus servers, others by cloud suppliers.
For intelligence work the list matters because each service attracts different attacks and keeps different records. The learning platform serves 6,000 users and is a frequent target of plugin advisories, while the finance system handles payments and attracts invoice fraud. Tomás notes for every service whether it runs on campus servers or with a cloud supplier, since that decides who can search its logs.
1.2 Exposure
The learning platform, email, website and remote-access gateway are reachable from the internet. Exploit Public-Facing Application (T1190) and Phishing (T1566) are therefore the first ATT&CK techniques Tomás reads about. The finance system is internal only, but reachable from staff desktops.
Internet exposure decides which advisories need action within hours and which can wait for routine review. An advisory about a learning-platform plugin matters at once, because anyone on the internet can reach the platform. An advisory about the finance system matters less urgently, but staff desktops that read email can still be used as a path to it.
1.3 Logs and owners
Each service has an owner and logs: the email gateway logs messages; the remote-access gateway logs connections; the learning platform logs logins. Tomás builds a table with service, owner, log location, retention and who can search it.
Without this table, a matched indicator sits in a ticket while Tomás asks around for the person who can search the right log. The retention column also tells him in advance whether an old indicator can still be checked at all. The table is reviewed with each owner once a term, alongside the service diagram.
1.4 Dependencies
The learning platform depends on the directory for logins. If attackers steal directory credentials, they reach every service that trusts it.
Tomás records this dependency in the service table, so an advisory about stolen directory credentials goes to every owner whose service trusts the directory, not only to the identity team. The learning platform, email and remote-access gateway all sit behind the same logins. A single reused student password can therefore open more than one service, which is why credential notices are handled urgently.
1.5 Supplier-hosted services
Cloud email logs sit with the supplier. Ashgrove's contract allows downloading sign-in logs for 30 days; older ones are gone. Tomás notes that limit, because intelligence about last quarter's attacks cannot be checked there.
The thirty-day limit is a contract term, not a technical choice that Ashgrove can change on the day. When an ESX report describes attacks from two months ago, Tomás writes that cloud email sign-ins could not be checked and gives the reason. He also records the limit in the service table so the gap is visible during contract renewal.
1.6 Students as users
Students use personal devices on campus Wi-Fi. The college cannot install agents on them, so intelligence about malware on student laptops leads to network controls and advice, not endpoint rules.
Because the college cannot see inside student laptops, the campus resolvers and Wi-Fi translation logs are its main view of them. An indicator matched from a student device ends with a network block and advice from the help desk, as in the Wi-Fi case. Tomás never asks a student to hand over a personal laptop for checking.
1.7 A service diagram
A one-page diagram showing services, users, internet exposure and log locations helps everyone place an advisory quickly.
Tomás keeps the diagram to one page so it can be printed and checked in a meeting with service owners. Each box shows the service, its owner, whether it faces the internet and where its logs are kept. When the ESX plugin advisory arrived, the diagram and the service table together let him reach the e-learning owner within the hour. A printed copy hangs beside the team's desk, so visitors from other teams can find their service on it quickly.
Worked example
ESX shares an advisory about attacks on a learning-platform plugin. Tomás checks the service table: Ashgrove's platform is internet-facing, uses the plugin and has an owner in the e-learning team. He sends the advisory to that owner with the version number, marked TLP:GREEN, within the hour.
Synthetic case. Ashgrove College and the advisory are invented.
Errors and limits
Diagrams drift; review them each term.
Exercises
- EX001 — First techniques. Which two ATT&CK techniques match Ashgrove's internet-facing services first, and why?
Show marking criteria
Rubric: 3 = T1190 and T1566 with reasons; 2 = names; 1 = one; 0 = none. - EX002 — Log retention gap. Why can't Tomás check last quarter's attacks in cloud email sign-in logs?
Show marking criteria
Rubric: 3 = 30-day retention by contract; 2 = partial; 1 = no access at all; 0 = none. - EX003 — Directory dependency. Why does stolen directory access matter so much?
Show marking criteria
Rubric: 3 = all services trusting directory become reachable; 2 = partial; 1 = only directory affected; 0 = none. - EX004 — Student devices. What kind of controls follow from malware intelligence about student laptops?
Show marking criteria
Rubric: 3 = network controls and advice, not endpoint agents; 2 = partial; 1 = install agents; 0 = none.
Synthesis
Map services, exposure, owners, logs and dependencies so each intelligence item finds its target quickly.