Job project: security automation engineer
As the automation engineer in a fictional company’s security team you design, test and hand over inventory, audit, detection and response tools.
Level 501 · 12 lessons · 12 practice labs
Lessons
Understanding the need
- Gathering and prioritising the team’s needs
- Tool architecture: modules, data flow, storage
- Threat-modelling your own tool
- Short task: write your design document and flag its risks
Building
- Syncing the asset inventory from several sources
- Scheduled audits and storing results
- An automatic flow from alert to ticket
- Deploying the tool with least privilege and protected secrets
- Short task: present the evidence your tool produced in an incident drill
Handing over
- Metrics: how much time you saved
- Runbook and failure modes
- Capstone: an end-to-end security automation package handed over to the team
Practice labs
- Rank the team’s requests: Turn the Atlas Clinic security team’s jumbled request notes into a requirements list ranked by impact and effort, and pick the three items for the first release with reasons.
- Threat-model your own tool: Draw the data flow of the given automation tool design, identify five risks from the credentials and privileges it holds, and write one control for each into the design.
- Gaps in the design document: Review a design document written by another engineer; find the single point of failure, the missing audit trail and the over-privileged service account, and present the corrected architecture in a short document.
- Sync the inventory from two sources: Write a sync script that merges the lab network scan result and the management system export into one asset inventory and flags conflicting records.
- A scheduled audit and its history: Run the audit tool regularly on a scheduler, store results in SQLite and show you can query when a finding first appeared and when it was closed.
- A flow from alert to ticket: Build a flow that enriches alerts from the lab log source and opens them in the mock ticket system, never reopens the same incident and loses no alerts while the ticket system is down.
- Measure the time saved: Produce a metrics report from the tool’s run logs with weekly automatically handled alerts, average handling time and the time it would have taken by hand.
- Deployment with least privilege: Move an automation tool that runs as root with its password in a config file to a dedicated service account, restricted permissions and a protected secrets file, and show it still works.
- A runbook and a failure drill: In the Blue Harbour Cargo lab, observe in a drill what the tool does when its log source is cut, its disk fills and the ticket system stops answering, fix the missing behaviour and write it into the runbook.
- Prepare an evidence bundle for a drill: Build an evidence index that lists the outputs the automation tool produced in an incident drill with timestamp, source and SHA-256 digest, and show that verification catches a change to any file in the bundle.
- Renew the tool’s access token without downtime: Renew the access token of the tool that connects to the mock ticket system without stopping the flow, and prove with logs that the old token is rejected and no alert was lost during the change.
- Tie the tool’s actions to a tamper-evident log: Make the automation tool in the Mavikaya Lojistik lab write every action to an audit log in which each entry is chained to the digest of the previous one, and prove the verification script points to the broken place when a line is deleted and when one is altered.
About this course
As the automation engineer in a fictional company’s security team you design, test and hand over inventory, audit, detection and response tools.
What you will learn
- Understanding the need
- Building
- Handing over
Prerequisites
You should be experienced in the topics of the same path up to level 401.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 501; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.