Skip to content
academia.sh
tr
Log in

Course Advanced

Runtime Security and Secrets Management

Published Updated

By the end of this course

Start course

01

Application Defense

Counting, in the same run, what defenses placed at the request layer at runtime catch, miss, and falsely block: the joint movement of three numbers against the anomaly score threshold of a ready-made rule set, the requests three rate limiting windows cut from legitimate peak load, the attack shape that account and address thresholds each see separately against credential stuffing, the number of applications covered and the endpoints left outside when security headers are managed from the server, and the delay in minutes with which application-level anomaly scoring flags a session that deviates from its baseline, together with the earlier stage at which each item could have been closed.

  1. 01 Web Application Firewall Running a ready-made rule set over a fictional daily request set and writing three counts separately: bad requests blocked, bad requests missed, and legitimate requests falsely blocked; how the three move together when the anomaly score threshold is lowered, what price writing exclusions pays to bring the same three counts back, and how much of the blocked volume could have been closed at a cheaper stage.
  2. 02 Rate Limiting Windows Running the same five-minute load through three different rate limit windows and how the window shape shifts the three counts: the window boundary effect of the fixed window, the request the sliding window cuts from legitimate peak load, the token bucket saving the peak share while also letting the attack peak through, how many bad requests the limit that saves the legitimate peak lets go, and which part of the cut volume could have been closed at an earlier stage.
  3. 03 Credential Stuffing Defense Running account and address thresholds separately over a one-hour login attempt record and separating which threshold stops which attack shape: the account threshold stops brute force and the address threshold stops concentrated-source spraying, while stuffing with a single attempt per account passes both; the gap between the number of attempts blocked and the number of account takeovers prevented, and the lockout of the shared egress address and of the legitimate account being targeted.
  4. 04 Security Headers Coverage Measuring with four separate counts the endpoints, applications, and requests covered by moving security headers out of the application and managing them at the edge: the daily requests carried by browser surface that does not pass through the edge, the cells configured but ineffective on endpoints with no browser surface, the number of legitimate pages a strict content security policy breaks, and the code-stage work needed before the policy can be tightened.
  5. 05 Application-Level Anomaly Detection Running seven sessions scored against a role baseline through a forty-five-minute behavior log and comparing the flagging threshold across four settings: the delay between the minute the deviation began and the minute the flag was raised, the number of records that left during that delay, the score gap between the slowly deviating insider threat session and the legitimate analyst session in the billing period, and how many records earlier the same leak could have been closed at the design stage.

02

Secrets Management

How the keys and credentials an application carries are held at runtime is measured in numbers: the secret store's access matrix and the items that least privilege closes, the startup dependency the store opens as a single point, how many times a short-lived credential narrows the exposure window and the request load it brings in return, the minimum overlap during which two secrets are valid together in key rotation and the requests a wrong ordering cuts, the static secrets that workload identity eliminates and the external-system items that remain, and the minutes from detection to revocation in the leak-response flow and the calls made with the secret in that time.

  1. 01 Secret Store Architecture The secret store is measured in terms of access control: the path-prefix policy opens 79 (app, secret) items to nine apps, the 90-day read log says 31, and 48 items sit there never used. No app reads three of the secrets; six apps can reach the widest data secret. The price of centralization is a single point — none of the nine apps can start without the store, and 41 start attempts a day pass through that one point.
  2. 02 Short-Lived Credentials The time from the moment a secret leaks to the moment it expires on its own is measured: in 16 of 31 items the exposure window drops from 90 days to 64 minutes, a factor of 2,033; in the remaining 15 items it does not shrink at all, and after the move 99.96% of the total exposure gathers there. The cost is not the total of store requests but their distribution — the load of three apps grows by 6.3 to 14.5 times, 1,073 temporary credentials a day are born and die on the target systems, and the number of apps that go down in a two-hour store outage rises from four to eight.
  3. 03 Key Rotation Rotation is measured in terms of the window in which two secrets stay valid together: the minimum overlap of seventeen secrets lies between 60 and 1,440 minutes, averages 815 minutes, and in eleven of them four apps that read only at startup set the window alone. When the overlap is kept short the arithmetic reverses — in a 60-minute window 36 clients miss the new value and 87,427 legitimate requests are cut, and when the order is reversed even the one app that reads on every request is cut. The same window drops from 1,440 minutes to 240 minutes when refresh-on-auth-failure is added.
  4. 04 Workload Identity Workload identity is measured with a single number: how many static secrets it replaces. Twenty of the thirty-one items disappear, eleven remain, and all of the remainder gathers in six secrets — the keys that sit on the signature-verifying side and the external providers that do not support federation. Of the nine apps only two come to carry no static secret at all, and seven keep carrying at least one. The trust relation that replaces the secret does not reduce the item count; it reduces how leakable the item is — and when written at the group level it opens 36 pairs instead of 20.
  5. 05 Leak Response Leak response is run as a revocation flow: across the remaining six static secrets, 1,386 minutes pass on average from the leak to revocation and 4,650 minutes in the worst item, and 224,171 calls pass through the secrets in that time. An ownership record gains 340 minutes and a pre-staged replacement gains 465; continuous repository scanning gains nothing because only two of the six leaks land in a repository. Revoking without waiting for propagation saves 150,934 calls but cuts 68,503 legitimate requests — one cut request for every 2.2 calls saved.

03

Infrastructure Posture

The runtime posture of the layer beneath the application is measured with numbers: the lateral-movement pairs closed by service-to-service authentication and the items certificate management adds, the processes that deviate from the baseline in container runtime detection along with false positives and detection latency, the legitimate deployments rejected by admission controller rules and the number of teams affected when moving to enforce mode, the findings returned to application teams and the unowned findings in continuous configuration auditing, and how many days rebuild-based updates cut patch lag to and the disruption they bring in return.

  1. 01 Network Segmentation and Service Zero Trust Lateral movement is counted in service pairs: of the nine services' 72 directed pairs, 52 pass the network policy and only 17 correspond to a legitimate call. One-way transport verification and mutual verification without an allow list close zero pairs; a per-caller allow list closes 35 pairs and brings average reach down from 7.1 to 4.1, but all eight of eight are still reachable from the edge service and the secret store is at most two hops away. The price is 31 certificates, 11,315 renewals a year at a short life, and 3.8 legitimate pairs lost per service.
  2. 02 Container Runtime Detection Four baselines are run on the same cluster over a week of process launch records: the image inventory catches 5 of the 21 anomalous events and misses 16, seven days of learning catches 12 but turns 9 legitimate events into false positives, writing the allow list as pairs brings the false positives down to 4, and writing it as binaries drops the caught events to 6. Detection latency is 17 seconds in stream mode and 47 seconds in batch mode, and only 8 and 6 of the 12 caught events arrive while the process is still running; 90.9% of the 68,746 events the pipeline carries deviates in no baseline, and narrowing the image from 342 binaries to 41 pairs gives the same three numbers without building a learning window.
  3. 03 Admission Controller Ten admission rules are run over 22 cluster objects: of the 35 violations, 22 are defects, 8 are justified needs and 5 are object types the rule does not fit. If enforce mode is switched on all at once, 21 objects are rejected, 5 of them legitimate deployments, and all five teams are affected; when the rules are ordered by defect ratio, the first six rules close 19 of the 22 defects with zero legitimate rejections, and the last three rules reject four legitimate deployments without closing a single defect. An exclusion is 13 rows per object, or 7 rows per namespace covering 38 cells and silently exempting one defect; all ten rules can also run at the pipeline gate, and the defects that can be closed only at the admission gate number 3.
  4. 04 Continuous Configuration Audit The 147 open findings of continuous audit are run through the ownership resolution chain: the owner label resolves 65 of them, namespace ownership 24 and repository path mapping 18, and 40 (27.2%) remain unowned. 81 of the findings fall to application teams and 26 stay with the platform; because the capacity of the 40 unowned findings is zero, the queue grows to 112 in twelve weeks while the backlog of the fixing teams shrinks. 31 of the unowned findings are on resources outside the cluster, and no cluster mechanism can resolve them; 122 of the 147 findings could have been closed at an earlier stage, but for 25 of the 40 unowned findings there is no earlier stage.
  5. 05 Rebuild-Based Update The same base image fix is run on thirty-one replicas by three paths and patch lag is measured in days: in-place patching closes the whole fleet in 5.25 days, but protection disappears after 2.61 days on a replica-weighted average and 72.8% of thirty days is spent open; a rebuild tied to a code change closes the last replica in 14.25 days and the open share is 19.4%; a scheduled rebuild closes all nine services in 1.75 days and brings the open share down to 5.8%. The price is a 31.6% rise in weekly replica restarts, from 73.5 to 96.75; services with two replicas lose half their capacity for ninety seconds on every round.

Final exam

Runtime Security and Secrets Management — Final Exam

In preparation

This course's question bank is not complete yet. The exam opens here automatically once enough questions are added.

Start typing to search.

↑↓ ↵ Esc navigate · open · close