7 Security Tools and Operational Exercises

A repeatable security cycle

Security tools are most useful when their findings support a repeatable cycle: identify assets and access, assess risk, apply controls, monitor for change, respond to incidents, and verify recovery. Tools provide evidence, not automatic conclusions. Validate findings in context, consider business impact and exposure, and record what was checked and changed.

Practice only on systems you own or are explicitly authorized to assess. Use isolated lab accounts and virtual machines, and do not scan or take response actions against production systems without approval.

Choose tools for the task

The practical toolset spans access review, configuration assessment, vulnerability discovery, monitoring, and response. Each tool supports a task; its result still needs to be validated.

• Identity and access management (IAM): AWS IAM and IAM Access Analyzer help review identities, permissions, trust relationships, and unintended external access.

• Hardening: CIS Benchmarks and OpenSCAP compare system configuration with a selected security baseline and identify gaps.

• Vulnerability management: Trivy, OpenSCAP, and authorized network vulnerability scanners can find known vulnerabilities or configuration weaknesses in software, images, and systems.

• Security monitoring: CloudTrail, a SIEM, and operating-system and application logs can collect and correlate events and alert on suspicious or unexpected activity.

• Incident response: Ticketing and case-management tools, log search, and endpoint tools help record evidence, coordinate containment, track remediation, and document recovery.

Review and improve access

Review access in a sandbox account or a mock policy document. The goal is to understand which identity can perform an action, on which resource, and why.

1. List identities, groups, roles, and long-lived credentials. Identify who or what uses each one.

2. Review permissions for broad actions or resources, unused credentials, and unexpected trust relationships. Where available, use IAM Access Analyzer and access-activity reports.

3. Create a task-specific role or policy with only the actions and resources needed. Prefer temporary credentials and MFA for human access; reserve administrative access for approved tasks.

4. Test the policy in a simulator or sandbox. Confirm that the required action succeeds and an unrelated action is denied.

5. Record the owner, purpose, review date, and rollback plan. Remove or reduce old permissions only after confirming dependencies.

Least privilege means granting only the permissions needed for the task. It does not mean breaking a workload by removing access it requires.

Harden and verify a host

Use a disposable virtual machine and choose the CIS Benchmark or other approved baseline that matches the operating system and its intended role. Baselines are starting points, so check for operational impact before applying changes.

1. Record the VM image, installed software, open services, and current security settings.

2. Assess the configuration with OpenSCAP and a compatible SCAP data stream and profile. For example:

1. Review failed checks. Prioritize relevant issues such as unnecessary services, weak authentication settings, missing updates, or overly permissive file access.

2. Apply changes one at a time, keeping a snapshot or rollback path. Do not blindly apply automated remediation.

3. Re-run the assessment, compare results, and document exceptions with an owner and review date.

A passing baseline report is evidence about the selected checks and profile, not proof that the host has no vulnerabilities.

Find and remediate vulnerabilities

Scan a local project or container image that you own. A Trivy filesystem scan can be started with:

For each finding, verify the affected component and version, whether it is actually present or reachable, whether a fixed version exists, and whether the asset is exposed. Prioritize using severity together with exploitability, business importance, and available mitigations—not severity alone.

Track findings in a register with the asset, component, vulnerability identifier, evidence, priority, owner, due date, action, and verification result. Update or replace the affected dependency in a test environment, re-run the scan, and then deploy through the normal change process. If a fix is unavailable, document a time-limited mitigation and its owner.

A scanner's reported fixed version is a remediation lead, not proof that upgrading is safe or that the issue is fully resolved. After a change, re-scan the correct artifact or asset.

Monitor and investigate activity

Enable logs for relevant identity, system, application, and network events. Centralize them where feasible, restrict access, use consistent timestamps, and set a retention period appropriate to organizational policy.

In a sandbox, create a small detection exercise:

• Generate a permitted failed sign-in or access-denied event.

• Make a documented, harmless test change to a lab IAM policy.

• Search the audit trail for the actor, time, source, action, affected resource, and outcome.

• Correlate the event with related system or application logs.

• Write a detection note describing expected behavior, suspicious variation, and how an analyst should validate an alert.

For AWS environments, CloudTrail records IAM and AWS STS API activity. Its events can help investigate who made a change, when, and from where. Confirm that the required event sources and ongoing log delivery are configured for the lab; having a service available does not guarantee that every desired log is retained or monitored.

An alert is a lead to investigate. Confirm it against independent evidence and normal activity before declaring an incident.

Respond to a simulated incident

For a simulated incident, monitoring reports an unexpected permission change in a lab account followed by an unfamiliar access-denied event. Do not create or expose real credentials. Work from a prepared event record or make a harmless change in an isolated sandbox.

1. Triage: Record the alert, time, affected identity and resource, and initial evidence. Decide whether the event is expected, suspicious, or confirmed malicious.

2. Scope: Search audit events and related logs for the same principal, policy changes, sign-ins, and affected resources. Preserve relevant records and note the time range and queries used.

3. Contain: In the sandbox, remove the unauthorized permission or disable the affected lab credential using an approved action. Consider service impact and preserve evidence first when feasible.

4. Eradicate and recover: Correct the underlying policy or configuration issue, rotate affected credentials if applicable, restore the intended access, and verify service behavior.

5. Learn: Document a timeline, decisions, evidence, impact, recovery checks, and follow-up work. Improve the detection rule or preventive control that could reduce recurrence.

Response is not just containment: preparation, analysis, communication, recovery, and lessons learned all matter. Follow the organization's incident-response plan and escalation requirements for real events.

Connect findings to verified recovery

Run this tabletop-and-lab exercise with a partner acting as the analyst. Keep all actions within an authorized sandbox.

1. Review a test identity and find an unnecessarily broad permission.

2. Record the finding, its risk, and the proposed least-privilege change.

3. Apply the approved change in the sandbox and verify required and prohibited actions.

4. Locate the policy-change event in the audit trail and confirm the identity and timestamp.

5. Simulate an unexpected follow-on action using a prepared event record. Triage it, determine its scope, and document a containment decision.

6. Re-scan or re-assess the relevant policy and configuration. Confirm that the weakness is corrected and required service behavior remains intact.

7. Produce a short report containing evidence, actions, residual risks, owners, and prevention improvements.

A useful outcome is a traceable chain from finding to risk-based decision, authorized change, monitoring evidence, and independent verification—not simply a tool finding a problem. Use IAM tools to inspect and narrow access, hardening tools to compare systems with an appropriate baseline, vulnerability scanners to identify and prioritize weaknesses, monitoring tools to collect and correlate events, and incident-response procedures to contain, recover, and learn. Preserve evidence and verify that remediation worked without disrupting required operations.