Listen to this Post
Introduction:
A provocative LinkedIn post from a seasoned industry expert has ignited a crucial conversation about the definition of a “real” security professional. The narrative challenges the prevailing authority of Governance, Risk, and Compliance (GRC) personnel, who often prioritize certifications and paperwork over hands-on technical execution and control validation. This exposes a fundamental rift in the cybersecurity field between perceived authority based on credentials and actual authority derived from technical capability and real-world impact.
Learning Objectives:
- Understand the critical differences between theoretical compliance (GRC) and practical, technical security implementation.
- Learn the essential hands-on technical skills—from penetration testing to cloud hardening—that define operational security expertise.
- Develop a methodology for validating security controls beyond questionnaire-based assessments.
- Explore the evolving vulnerability management landscape beyond the traditional CVE system.
- Gain insights into building a risk management program owned internally, not outsourced to external scoring systems.
You Should Know:
1. The GRC vs. Technical Security Divide
The core conflict highlighted is between security as a bureaucratic function and security as a technical discipline. GRC professionals often “attest” to risk assessments they didn’t author and enforce policies they couldn’t implement technically. A real security professional understands that a control isn’t secure because a policy says it is; it’s secure because its technical implementation has been validated.
Step-by-step guide to control validation:
- Identify the Control: For example, “Ensure multi-factor authentication (MFA) is enabled for all administrative access.”
- Move Beyond the Checkbox: Don’t just ask, “Is MFA on?” Instead, technically verify it.
3. Technical Verification on Azure AD:
Connect to the tenant: `Connect-AzureAD`
Fetch the conditional access policies to see enforcement: `Get-AzureADMSConditionalAccessPolicy`
Use the Microsoft Graph API to query user MFA registration status directly.
4. Technical Verification on AWS IAM:
Check for a password policy that enforces MFA: `aws iam get-account-password-policy`
Use a tool like `ScoutSuite` or `Prowler` to audit the entire environment for MFA compliance on privileged users: `prowler aws –group iam`
5. Conclusion: The control is only validated when you have technical proof, not a verbal or form-based affirmation.
- From Risk Assessment Theory to Penetration Testing Practice
The author mentions having “pentested” ASX100 companies. A risk assessment identifies potential weaknesses; a penetration test provides the technical evidence of their exploitability. GRC often owns the risk register, but technical security owns the proof.
Step-by-step guide for a basic web application penetration test:
1. Reconnaissance: Use `subfinder` and `amass` to enumerate subdomains.
Command: `subfinder -d target.com -o subdomains.txt && amass enum -passive -d target.com -o amass_subs.txt`
2. Discovery & Fingerprinting: Use `httpx` to find live hosts and `nmap` to fingerprint services.
Command: `cat subdomains.txt | httpx -silent | tee live_hosts.txt`
Command: `nmap -sV -sC -iL live_hosts.txt -oA service_scan`
3. Vulnerability Scanning & Exploitation: Use `nuclei` with the community template list to check for known vulnerabilities.
Command: `cat live_hosts.txt | nuclei -t cves/ -o nuclei_findings.txt`
4. Manual Testing: Actively test for logic flaws, broken access control (e.g., changing a user ID in a `GET` request to access another user’s data), and SQL injection using tools like sqlmap.
Command: `sqlmap -u “https://target.com/user?id=1” –batch –level=3`
5. Reporting: The final report must link the exploited vulnerability back to the risk identified in the assessment, closing the loop between theory and practice.
3. API Security and Cloud Hardening Beyond Questionnaires
The author alludes to “defining the security standards that they refer to every day,” such as “TLS for all of AWS.” This is the implementation of secure defaults, a technical act far beyond writing a policy.
Step-by-step guide to enforcing TLS 1.2+ in AWS:
- Create a Custom SSL/TLS Policy in AWS ELB:
Navigate to the EC2 Console -> Load Balancers -> Create Load Balancer.
For an Application Load Balancer, in the “Security settings” section, you cannot directly create a custom policy. Instead, you must use the AWS CLI. - Using AWS CLI to set a strong security policy:
First, list available policies to find the one that disables old TLS versions: `aws elb describe-load-balancer-policies`
For a new or existing Classic Load Balancer, you can set the policy: `aws elb set-load-balancer-policies-of-listener –load-balancer-name my-lb –load-balancer-port 443 –policy-names ELBSecurityPolicy-TLS13-1-2-2021-06`
3. Infrastructure as Code (IaC) Enforcement: Use Terraform to harden your cloud setup by default. In your `aws_lb` resource, set the `ssl_policy` attribute.
Code Snippet:
resource "aws_lb_listener" "front_end" {
load_balancer_arn = aws_lb.front_end.arn
port = "443"
protocol = "HTTPS"
ssl_policy = "ELBSecurityPolicy-TLS13-1-2-2021-06"
certificate_arn = aws_acm_certificate.example.arn
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.front_end.arn
}
}
4. API Security Testing: Use a tool like `kiterunner` to discover and brute-force API endpoints that traditional scanners miss.
Command: `kr scan https://api.target.com -w ~/wordlists/data/routes-large.kite`
4. The Myth of CVE and Modern Vulnerability Management
The post criticizes the blind faith in the CVE system, noting the author’s own role in a Global Numbering Authority (GNA). The CVE system is slow and often lacks context. A modern professional uses it as one source among many, not the sole source of truth.
Step-by-step guide to a superior vulnerability management process:
- Data Aggregation: Use tools to aggregate data from Software Bill of Materials (SBOM), cloud security posture management (CSPM), and Software Composition Analysis (SCA).
Command (using Syft to generate an SBOM): `syft packages alpine:latest -o spdx-json > sbom.json`
2. Prioritization with EPSS: Use the Exploit Prediction Scoring System (EPSS) to prioritize vulnerabilities based on the likelihood of exploitation, not just the CVSS score.
Use the EPSS API: `curl -s “https://api.first.org/data/v1/epss?cve=CVE-2023-34362” | jq .`
3. Context is King: Correlate findings with internal telemetry. Is the vulnerable service exposed to the internet? Is it running in a production environment? Are there existing compensating controls? - Automate Remediation: Integrate this pipeline with CI/CD to automatically block builds with critical, exploitable vulnerabilities, shifting security left.
-
Owning Your Risk Program: From External Scores to Internal Validation
The author warns against letting an “outsider own their risk program” via external risk scoring. A real security program is built on internally validated data and context-specific understanding.
Step-by-step guide to building an internal risk calculation:
- Define Your Formula: A simple, effective formula is:
Risk = (Threat Impact Likelihood) - Control Effectiveness. - Quantify Threat: Use your own threat intelligence—logs from WAF, SIEM, and EDR—to see what is actually being attacked. An external “high” score matters less than an internal “frequent attack” status.
- Measure Control Effectiveness: This is the key differentiator. Don’t guess. Test.
For EDR: Simulate an attack with `Atomic Red Team` and verify the alert is generated.
Command (Linux, simulating persistence via cron): `echo “/5 /tmp/malicious.sh” | crontab -`
For WAF: Launch a controlled, non-destructive SQL injection test against a staging endpoint and confirm it was blocked. - Build a Dashboard: Use data from your SIEM and vulnerability management tools to populate a live risk dashboard (e.g., in Splunk, Elastic, or Grafana) that reflects your internal reality, not an external vendor’s generalized score.
What Undercode Say:
- True security expertise is demonstrated through the ability to technically implement and validate the controls that GRC frameworks only describe on paper. Certifications attest to knowledge; practical skill attests to capability.
- The future of cybersecurity belongs to hybrids: professionals who can articulate risk to the C-suite in GRC terms and then descend into the command line to prove the controls are working as intended.
The post, while venting frustration, accurately diagnoses a systemic issue. The industry has created a class of security professionals who are managers of risk instead of practitioners of security. They are insulated from the technical reality of the systems they are meant to protect, relying on attestations and questionnaires. This creates a dangerous gap where organizations feel compliant but remain vulnerable. The solution is not to abolish GRC, but to demand that it be deeply integrated with and informed by relentless technical validation. The “real” security professional is the one who closes this loop.
Prediction:
The growing complexity of cloud-native and AI-driven systems will render purely checklist-based security obsolete. The “GRC illusion” will shatter under the weight of sophisticated attacks that bypass policy-based defenses. We will see a market correction: a sharp rise in demand for security engineers and architects who can codify security into infrastructure (DevSecOps, Policy-as-Code) and a devaluation of roles that cannot bridge the gap between theory and execution. Organizations that fail to integrate deep technical validation into their core governance processes will suffer disproportionate breaches, forcing a industry-wide redefinition of what it means to be a “real” security professional.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Chrisdlangton Youre – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
