This is my “what I’m actually going to do differently on Monday” post. Three takeaways that map directly onto the AI-risk work I’ve been running since September.
SANS AI Cyber Summit ran two days at the Hilton Arlington Rosslyn, plus pre-summit training options I didn’t take (Brights paid for the summit only, which was the right scope for a junior). The speaker list for the summit-proper included some heavyweights:
I’ll write up notes on individual talks separately if I get to them (unlikely — I’m behind on threat-intel digests). For this post I want to focus on the three meta-lessons I want to carry back into Brights’ ISO 42001 work.
Schneier’s keynote made a point I’ve been circling around in the Brights crosswalk work without articulating clearly: the AI-security field has spent ~3 years arguing about which framework (NIST AI RMF, ISO 42001, EU AI Act, OECD AI Principles, the various corporate “responsible AI” white papers) and is now starting to converge on a shared taxonomy underneath. The frameworks differ in form but are substantively quite similar:
ISO 42001’s 38 controls fit that 4-bucket structure cleanly once you read past the language. So does NIST AI RMF 1.0 (Govern / Map / Measure / Manage). So does the EU AI Act (categorised by risk-tier).
What I’m doing differently: restructuring the Brights crosswalk matrix from “ISO 42001 control → existing engineering practice” into “shared 4-bucket category → ISO 42001 control + NIST AI RMF function + EU AI Act risk-tier mapping → existing engineering practice”. More work upfront; much less work when the next AI governance standard ships and we have to add another column.
Julie Davila’s talk was the operationally-richest one of the summit. The thesis: most AI-security disasters aren’t the spectacular prompt-injection-as-RCE we red-team about — they’re the boring seams between AI systems and the rest of the production environment. Specifically:
What I’m doing differently: adding a “boring seams checklist” section to the Brights AI-risk pre-deployment review template. Five items above plus the three from Anne Neuberger’s keynote (machine-speed-incident-response readiness, AI-system-incident runbook, supply-chain governance for model artifacts). Going to test it against the AI-services product the dev team is building this quarter.
Yevhen’s session was the only one that explicitly addressed the Ukrainian situation. The shape of his argument: the Russian APT operators (UAC-0010, UAC-0050, etc.) are already using LLM-assisted content generation for spear-phish landing pages and HTML lures — he showed concrete examples of generated lure content where the language tells (specific Ukrainian-vs-Russian word choices, missing post-2022 referent shifts) point at LLM generation. The defensive implication: detection rules that key on linguistic markers (“дякую за ваш звіт” vs the more colloquial “дякую за репорт” in context of a tech professional) may help fingerprint LLM-generated phish vs human-written.
This is downstream of detection-engineering work I’m already doing at Brights but it’s a good additional dimension.
I cornered Yevhen briefly after his session to ask one specific question — what does CERT-UA’s working relationship with EU CERTs look like in 2026, post-EUCC-rollout? His answer was nuanced and I’m not going to half-paraphrase it here, but the takeaway for me was: there are real research / collaboration opportunities for junior researchers in UA who are willing to write English-language content on UA-side threat observations. Nothing to act on immediately, but a thread to keep tugging.
A SANS summit is somewhere between a conference and a recruiting event. The keynotes are excellent; the breakout sessions are variable; the “networking” is important if you’re senior and optional-but-useful if you’re junior. As a junior I got a lot out of it because I went into specific sessions with specific questions; I imagine if I’d shown up without that I’d have come back with a worse report.
The Schneier “Integrous AI” keynote alone is going to be referenced in every cybersec conversation I have at Brights for the next year. Worth the whole trip just for that. I’ll re-watch the recording when SANS releases it.
Слава Україні. 🇺🇦
]]>I expected ISO 27001 ISMS work to be document-shuffling and policy maintenance. Bureaucracy. Update the risk register, file the audit-evidence folders, write a new policy when something breaks, repeat.
It’s not zero of that. But the actual day-to-day is much more cross-team negotiation — translating between what the standard requires, what the team’s existing practices actually do, and what’s realistic to change without breaking working processes.
A concrete example from this month: ISO 27001 Annex A.5.7 (Threat intelligence) says the org should “collect and analyse information relating to information security threats”. Brights had nothing formal in place — informal Slack channels where senior engineers occasionally shared CVE alerts, but no structured intake / triage / action loop.
The ISO-checkbox version of “fix this gap” would be: write a threat-intel policy, create a SharePoint page, declare done.
The actually-useful version is: figure out what threat intel a 50-person shop can realistically consume (we’re not staffing a 24/7 SOC team), how to triage it with junior-level effort (i.e. mine), what specific CVE/IOC subscriptions matter for our stack (Node, .NET, AWS, Azure, the specific OSS dependencies the dev teams use), and how to push something actionable to dev leads when something matters for our actual code.
The ISO checkbox is downstream of doing the practical thing. If you do the practical thing, the documentation writes itself. If you do the documentation thing first, you have a binder full of policies that nobody references. (Senior cybersec friends have been telling me this for years and I half-believed them. Now I believe them.)
Roughly:
The 25% on AI risk is what justifies the conference-travel sponsorship I got — Brights is positioning to add AI-services to their offering and the founders correctly identified that going from “27001 cert” to “42001 cert” requires real work, not just an additional binder. I’m the person doing that work, which is fortunate because it’s the most intellectually interesting part of the role.
A few specific items that landed:
Migrated the Suricata + ELK lab from my BSc thesis docker-compose into the Brights staging environment, on a dedicated VLAN. The ruleset is ~30 thesis rules + ~10 Brights-specific (we have a few Node + .NET specific ones now). Filebeat ships eve.json into the Elastic cluster. Nothing fancy, working baseline.
Wrote a one-page “ISO 27001 control → engineering practice” crosswalk for the dev leads. Most engineering teams don’t have time to read the full standard. I read it, summarised the 93 Annex A controls into “what does this actually mean for someone writing Node code at a 50-person agency”, attached examples. Got useful feedback (“we already do this implicitly”, “we don’t do this at all”, “we do a worse version of this”) that’s now driving the gap-track.
Built a quarterly threat-intel digest template. Sources: CERT- UA bulletins (UA threat angle), CISA KEV catalog (urgent CVE), our AWS/Azure security advisories, npm/NuGet security advisories (matched to our actual dependency tree). Triaged outputs go to dev leads in a 1-page Friday email. First issue ships next Friday.
Started the ISO 42001 readiness gap analysis. This is going to take months. I’ve spent the September window reading the standard cover-to-cover, mapping the 38 controls, and starting the AI-RMF crosswalk. Not done. Probably won’t be done by Christmas.
A short and humbling list:
I’ll write more as I have more to say. Probably the next post is either the November surveillance-audit retrospective, or whatever I take away from BSides SF in March.
(I picked Brights specifically because the cybersec function was nascent enough that I’d get to build parts of it, not just operate parts of it. That call has held up after one month — first-junior-hire roles trade ambiguity for ownership, and I’m getting both in appropriate doses.)
Слава Україні. 🇺🇦
]]>Behavioural Anomaly Detection in Network Traffic via Suricata IDS and ELK Stack: A Sandbox-Based Approach to Identifying APT Lateral Movement Patterns.
The full abstract sits on the thesis page and the supporting code is at github.com/palianytsia-200/suricata-elk-lab. This post is the slightly more honest “what really happened during the year” supplement that doesn’t go in the academic version.
Final grade: 92/100 (A). Solid but not top-of-cohort — there are 4–5 ФТІ ‘25 graduates who scored higher and they all earned it. I’m okay with where I landed.
Picking a topic where I could actually replay traffic. Half the behavioural-detection literature feels theoretical because the authors don’t have access to attacker traffic to test against. By deliberately constraining the empirical chapter to public Malware- Traffic-Analysis pcaps + a few synthetic captures from my home lab, I bounded the project to something I could finish. The temptation to expand to “and also test against real enterprise traffic” was strong; resisting it kept the deadline reachable.
Docker-Compose for the lab. Reproducibility is the boring word that academic supervisors keep saying and I sort of nodded along without internalising. Then around chapter 4 my lab broke, I had to rebuild it on a different laptop, and I lost a week. After that, the Docker-Compose was non-negotiable. The whole lab now spins up in 90 seconds on a fresh machine.
Dropping a chapter early. My original plan had a chapter on Active Directory enumeration detection that turned out to require an AD environment I didn’t have a clean way to build. My supervisor suggested cutting it in chapter 3 review. I argued for keeping it. She was right; I should have cut earlier. The trimmed thesis is more focused and the AD chapter would have been weak.
Starting the empirical chapter early. I ran rule-tuning loops in parallel with chapter 2 writing. By the time I needed to write up chapter 4 (empirical), I had three months of tuning iteration already done.
Wider replay corpus. I leaned heavily on Malware-Traffic- Analysis pcaps because they’re well-documented, but they’re also curated for clarity. A real enterprise capture would be messier and the ruleset’s false-positive rate against it would have been more illustrative. If there’s an MSc continuation, that’s the v2 angle.
More time on the “why” of behavioural cumulative scoring. I described the technique well enough but didn’t go deep enough on the theoretical scaffolding (Bayesian belief updating? hidden Markov model framing?). My committee asked exactly this question during defence and I had a competent but not great answer.
A baseline against Zeek. Suricata is a great IDS but Zeek’s logging-first model is conceptually different and would probably have been a fairer comparison than a vanilla-Suricata baseline. Did not have time. Future work.
Earlier supervisor review on the empirical chapter. I waited too long to show drafts. When I finally sent the empirical chapter four weeks before defence, my supervisor flagged a methodology issue (I was conflating “rule did fire” with “rule fired correctly” without clean ground-truth labels) that took two weeks to fix. Lesson: supervisor review every two weeks, not every two months.
A few things that I think will follow me into actual SOC work:
Detection engineering is a tuning loop, not a writing exercise. Writing a rule takes 30 minutes; tuning it to acceptable false-positive levels in a target environment takes weeks. A SOC that ships rules without budgeting for the tuning is going to drown in alerts. (Brights doesn’t have a SOC yet — I’m walking in to build one — and I keep this as a principle.)
Cumulative-scoring approaches outperform single-rule detection, with constant tuning. This is the conclusion of my empirical chapter and I believe it: the meta-rule “five low-severity events in a 60-second window from the same source” caught attacker patterns that any individual rule missed. But it requires continuous environment-specific tuning — turn that knob too tight and you false-positive on benign automation; too loose and you miss real attacks. The tuning loop is the work.
Replay-pcap-driven empirical work is wildly underutilized in academic cyber programmes. Most thesis-level work I’ve seen at KPI is theoretical or simulation-based. There’s huge room for pure-replay-pcap experimental work, and the public corpus (MTA, the various .pcap libraries on GitHub) is generous. If you’re a future ФТІ student looking for a thesis topic, this is a mineable seam.
Returning to Brights as a full-time Junior Cybersecurity Specialist in September. They’ve been an absurdly generous host of an academic-research-flavoured intern (me, 2024 summer) and seem genuinely interested in growing the cybersec function around the ISO 27001 / 42001 work. I’ll get to actually deploy some of the detection rules from the thesis against a real (small) production environment, which is exactly the kind of practical follow-on the thesis lacked.
The summer between defence and start date is for: catching up on sleep, reading the books I procrastinated on for six months (Secure by Design, Building Secure & Reliable Systems, the Anton Chuvakin newsletter archive), and a small Carpathian hiking trip.
Слава Україні. 🇺🇦
]]>Pterodo HTML / VBS implants from late-2024 onwards beacon to URLs of the form:
http://<bare-IPv4>/<verb><suffix>?-<DD>-<MM>
Where:
<bare-IPv4> = a literal IP, no Host header pointing to a hostname.
This is the high-fidelity bit — bare-IP HTTP traffic from a workstation
to an external IP is almost never legitimate in 2025. (Cloud control
planes, CRL distribution, and a few niche update mechanisms aside.)<verb> = a short alpha string. Observed: Svvr, SSsr, Akad,
Akk, Gpps, Mouuds. Five of six are double-letter alliterative
(vv, Ss, kk, pp, uu). The doubled-letter is consistent with
Gamaredon’s well-documented alliterative-naming TTP — the same
pattern produces riontos.ru-style apex names.<suffix> = Htm, Ua, U, or empty. Sometimes encodes campaign
variant or victim cohort.<DD>-<MM> = the campaign date, baked into the URL path at
generation time. Two-digit zero-padded.alert http any any -> any any (
msg:"GAMAREDON Pterodo bare-IP beacon URL (alliterative path + DD-MM date)";
flow:established,to_server;
http.method; content:"GET";
http.host; pcre:"/^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}(:80)?$/";
http.uri; pcre:"/^\/[A-Z][A-Za-z]{2,7}-\d{2}-\d{2}\/?$/";
classtype:trojan-activity;
sid:9001502;
rev:2;
metadata:mitre T1071.001 T1568.002;
reference:url,cert.gov.ua/article/...;
)
The two pcre clauses are the meaty bit:
http.host matches a bare IPv4 (with optional explicit :80). This
is the hard-to-evade signal — Pterodo’s HTML/VBS landers are
hard-coded to fetch bare-IP URLs, and changing that requires
re-tooling.http.uri matches a path of: leading slash, capital letter, 2–7
more letters (mixed case), dash, two digits, dash, two digits,
optional trailing slash. That covers the observed verbs and
suffixes without enumerating them.I deliberately did NOT enumerate the specific verb list (Svvr,
SSsr, etc.) — operators rotate verbs across campaigns, and a rule
keyed on a fixed list would fail closed on the next rotation. Better
to match the path shape and accept some false-positive volume.
Things this rule will fire on that aren’t Pterodo:
169.254.169.254 (AWS, GCP) — the IP-only Host
header is right, but those URIs are typically not in the
<verb>-DD-MM shape, so the URI regex saves us. Negligible FP.http://10.0.0.5/Health-01-15
could match. Add a ! $HOME_NET filter on http.host. (My version
scopes destination as any because home-lab purposes; for
enterprise, scope it.)/crl/<name>.crl, not the
<verb>-DD-MM shape, so the URI regex filters this out too. Low.In my home-lab (the Suricata-elk-lab Docker-Compose I shipped with my BSc thesis support repo), the rule fires on:
nmap scans I run as part of CTF practice — zero hits (nmap doesn’t
do <verb>-DD-MM URIs).curl to bare-IP API endpoints I happen to use — zero hits.So in a low-noise environment, false positives look like zero. In a real SOC the actual answer depends on your environment — please tune before deploying.
Things this rule misses:
-DD-MM suffix — some Pterodo
variants (older, e.g. early-2024) used path forms without the date.
My rule won’t catch those. Different rule.For a small SOC (Brights-sized, ~50 staff) the rule is essentially
free to run. The bare-IP HTTP outbound is rare enough in modern
enterprise that it’s a high-confidence alert on its own; combining
with the URI regex makes it specific to the Pterodo shape. Cumulative
behavioural scoring makes this stronger — if a workstation also
recently downloaded an HTML attachment with a Scan_X_Y_Z_NNNN name,
you have a high-confidence Gamaredon detonation.
(Caveat: I’m a junior. This is rule-writing as a learning exercise, not as production guidance from someone with a decade of detection engineering. Run any rule through your own tuning loop before trusting it in alerts.)
To Florian Roth’s signature-base project for being the canonical example of “how to structure a public-facing detection rule”. Most of the formatting choices here are imitations of his.
]]>A few things jumped out that are worth turning into actual detection content for someone running a small-shop SOC. None of these are novel research; they’re me reading carefully and trying to translate “the bulletin says X” into “here’s what you’d watch for”.
Across the recent CERT-UA dispatches the HTML / VBS / SFX / RAR filenames have a bunch of recurring shapes:
Scan_<digit>_<digit>_<digit>_<NNNN>_<DD>.<MM>.<YYYY>.htm[l] — the
“Scan” prefix is recent (added late-Apr 2024 per CERT-UA’s wave
comparison). Most bulletins from the prior 12 months use the bare
<digit>_<digit>_<digit>_<NNNN>_<DD>.<MM>.<YYYY>.<ext> form.<DD>.<MM>.<YYYY> date convention is Russian / European
format (dot separators, day-first). Operator-side automation is
emitting filenames in Russian-locale date format, which is itself a
mild-fidelity signal — most Western scanners would emit ISO date,
not dotted-DDMMYYYY.These are CERT-UA’s published indicators; not me re-deriving from samples. But the regex shape is stable enough across bulletins that it’s worth a static-content rule. Suricata sketch (untested at scale — this is a thinking-out-loud rule, not a production-deploy one):
alert http any any -> $HOME_NET any (msg:"UAC-0010 Pterodo Scan_X_Y_Z filename pattern";
flow:established,to_client; http.uri;
pcre:"/Scan_\d+_\d+_\d+_\d{4}_\d{2}\.\d{2}\.20\d{2}\.html?/i";
classtype:trojan-activity; sid:9001500; rev:1; reference:url,cert.gov.ua/article/...;)
The 2 in \d{2}\.\d{2}\.20 is a poor hack to anchor on 20XX years.
Probably wants \.(202[4-9])\. instead. As written this rule will fire
on benign legitimate file uploads named with similar conventions — it
needs to_client flow direction, attachment-content-type checks, and
some host-filter to be useful in production. Take it as a sketch.
Per CERT-UA’s IOCs the recent waves carry beacon URLs like
http://<bare-IP>/<verb><suffix>?-<DD>-<MM> where:
Svvr, SSsr,
Akad, Akk, Gpps, Mouuds)Htm, Ua, or empty<DD>-<MM> is the campaign dateFive of those six verbs feature double-letter alliteration (vv,
Ss, kk, pp, uu) — that lines up with Gamaredon’s well-
documented alliterative-naming TTP, the same one that produces
riontos.ru style apex names with a recurring first letter. Whoever
designs the operator-side URL generator is consistent.
The detection-engineering useful bit isn’t the specific verb list (the operators rotate them), it’s the bare-IP plain-HTTP beacon to a double-letter URL path, which is a very high-signal shape for “something Pterodo-flavoured is calling home”. A Suricata sketch that matches the shape, not the specific verbs:
alert http any any -> any any (msg:"UAC-0010 plain-HTTP bare-IP beacon (alliterative path)";
flow:established,to_server;
http.host; pcre:"/^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/";
http.uri; pcre:"/^\/([A-Z][a-z]?)\1[A-Za-z]{1,4}-\d{2}-\d{2}/";
classtype:trojan-activity; sid:9001501; rev:1;)
That regex matches paths starting with one capital + one lowercase +
the same letter again (the alliteration), followed by 1-4 letters,
then -DD-MM. Imperfect — won’t catch the Akk / Akad shapes
because those don’t have lowercase before the doubled letter. Better
shape probably involves an explicit verb-list of the form
(Svvr|SSsr|Akad|Akk|Gpps|Mouuds) followed by suffix and date. Tune
to your environment’s noise.
Both shapes (the filename schema, and the beacon URL pattern) are
candidate examples for the empirical chapter — they’re cumulative-
behavioural signals where a single hit isn’t conclusive, but a
combination (“workstation downloaded a Scan_X_Y_Z_NNNN_DD.MM.YYYY.htm
attachment AND beaconed to a bare-IP URL with alliterative path
within 60s”) is high-confidence.
CERT-UA’s bulletins are extraordinarily generous publications and the quality is high. If you’re a UA cybersec student or a junior SOC analyst, the CERT-UA bulletin archive is one of the highest-density learning resources I know of for practising “TTP description → detection rule” translation.
(I’ve published the Suricata-elk-lab Docker-Compose I used for the thesis empirical chapter at github.com/palianytsia-200/suricata-elk-lab. Not production-ready — student work. But useful as a reproducible bench.)
]]>