Recruiters are noticing that while there are vacancies in information security, very few are entry level. Almost every job asks for prior experience.

Here's why.

1. Information security is mostly driven by laws and regulations.

2. Information security is still considered as an offshoot of IT. So much so, that having an IT experience is a definite '+'.

3. Infosec is a cost centre. Outsourcing is always a juicier option, than maintaining staff, in-house.

4. Security is like brushing your teeth or taking a daily bath - everyone knows the benefit, still very few people do it (unless forced, either by society or by regulation), unless they get compromised. It's a different ball-game then.

5. When an employer looks to bolster their security status, they hire

   1. The leader (CISO), if they are in a regulated industry or a decent size company. Hiring happens, top-down (senior-most, then senior, then junior, followed by junior-most).

   2. Someone slightly experienced, but cheaper than an executive.

6. Due to point 1 above, budgets are limited. Skill stacking is a given, resulting in cocktail JDs. Budgets get depleted by the time it comes to juniors.

One must read the below posts, related to job and work in general. Read them, chew them (in mind, of course).

End of Work - Daniel Miessler's theory on why it is so hard to find and keep a job that makes you happy.

Job security in cyber security is changing - Jai Minton's take on the changing job landscape in cybersecurity

Doesn't mean all is lost, though.

Here are some ways for an entry level guy to enter into this field. Remember - very few people can do all the things that are listed below. So, even if you could do 'some' things out of below list, congratulate yourself every-day. And push on.

Few non-negotiable pre-requisites first. These must be sorted out before you put in the hard work.

1. Why do you want to get into Infosec? Get your 'why' sorted out.

2. Understand your learning process, is it top-down or bottoms-up?

3. Understand the value that you bring to your employer - cheap, open for experiments, can be deployed for anything, always available. Not every senior can do this. This is your value to most of the employers (at least for the first 3-4 years). Remember this. And,

Remember to tell yourself every day - Hard choices, easy life. Easy choices, hard life.

After you sort the pre-requisites out, do the following while looking for a job in infosec. Keep updating your CV every 6 months. Keep a daily journal of things that you did at work and learning. It will help you when you update your CV (and in interviews). Remember - pivot when things doesn't seem to be going your way. But, give yourself time before deciding to pivot.

1. Invest in a desktop (not in that fancy laptop) and build a home-lab. Anant Srivastava has articulated it very well in his c0c0n talk 'Expanding capability horizons : Homelabs and beyond', watch and take notes.

   1. If you like offence, pick few vulnerable VMs, pick an introductory course (from TCM Academy; their YouTube channel has lot of useful info for no cost) and follow along.

   2. If you like defence, setup a defensive lab (an AD with DNS, couple of windows machines, 1-2 linux machines, one web server, etc.). Learn how to set up log forwarding, how to analyse logs. Hover to BTL, Let's Defend, or Chris Sanders' courses.

   3. Jason Haddix has some pointers for red, blue, and purple trainings that are available for free.

   4. If you are a developer who is looking to get into security, source code review, web app pentest are some of the ways you can contribute. Pentesterlab runs a very good source code review course that you can look into. It is not cheap ($950), but very systematic, with a worthy trainer. Their lab, even otherwise, is a good investment for people who want to get into web app security. Another excellent resource is from makers of Burp Suite Pro - the web security academy.

2. Document your experience. It is crucial because it tells a recruiter that you are hungry and that you are learning/ amenable to learn. Both are crucial traits that employers look for. It could be a blog, tweets, LinkedIn posts, etc.

   1. If you are learning offence, look for vulnerabilities in open source software, raise PR (Pull Request), and ask for CVE number when they accept your PR.

   2. If you are learning defence, document your journey of setting up your homelab, setting up logging, analysing those logs, identifying attacks, responding to them, etc.

3. After you have been at it for about 6 months (no less), try contacting CISOs in/ near your city using LinkedIn with crisp, 2-para cover letter. Highlight what you have been doing for your learning, and express interest in joining their team.

4. Visit resume clinics in conferences. Hand out your CVs. This will help you get over your shyness. It will be very difficult initially (doubly so if you are an introvert). Use LinkedIn if you can't visit personally.

5. First 2-3 years are very crucial, after you get a job. Think about them as investment. You need to optimise your initial days. Here's how.

   1. Spend some time (2-3 years) in IT, if your learning happens in a bottoms-up manner. Some of the options are -

      • Helpdesk - You will learn how an organisation works, how to troubleshoot basic issues in IT.

      • Supporting system/ network administrators - You will learn all the ways in which a server or network blows up, how users react, how sysadmins and network admins keep the mis-configurations alive, how they get flagged by auditors as security vulnerabilities, etc.

      • Junior developer - You will learn about how development happens, which will help you in setting up a Secure SDLC practice, or setup secure CI/ CD pipeline, or get into secure code review, or web app pen testing, etc.

   2. Spend some time in ISO 27001 implementation teams, if you happen to be a top-down person. You will learn more about how an organisation works, the processes interact, how work gets done at high level, etc.

6. Don't worry if you feel overwhelmed in one specialty (offence, defence, AD, app-sec, governance, compliance, etc.) and looking to pivot. Everything is connected in infosec. You must learn how to connect 'what you are doing now' to 'how will this help in your new role'. Here's an example. Doing application risk assessment is very hard if you don't understand

   1. key vulnerabilities (XSS, resulting in session hijacking; the application storing data on an S3 bucket which is unprotected),

   2. the business need of the application (used for customer Video-KYC, which is different from Customer-KYC),

   3. its placement in the network (how does risk changes when application and data are stored in vendor network vs. stored in your datacenter),

   4. applicable regulations (e.g., for Indian BFSI, RBI regulations around V-KYC, RBI cybersecurity framework, RBI master direction on IT Governance, RBI master direction on Outsourcing of IT activities, DPDP Act of India, etc.), and

   5. impact of exploit (session hijacking, coupled with open S3 bucket, leads to ATO - Account Take Over - and customer PII; potentially resulting in fine/ penalty).

7. What does the last example mean? It means,

   1. It is Ok to pivot to defence if you find offence overwhelming or not suiting your temperament. However, you must be clear on

      • why you are doing it, and

      • what value you bring to the other side, when you pivot (e.g., your application development skills make you a juicier candidate to IT, your understanding of application vulnerabilities and exploits make you a better risk assessor in InfoSec Governance or a better SOC analyst because you know application logs better than anyone, your experience in infosec governance makes you a better compliance officer, etc.)

   2. You must be honest with yourself. Are you pivoting because you know you don't belong to this sub-field or is it just laziness and lethargy? Sometimes, it takes time for information to seep into brain and crystallise into something actionable. Give yourself tough love, because no one else knows you like you do.

All the best for your future. May the force be with you.

Banking is a boring job for many.

Lot of processes, forms to fill (whether offline or online), detailed checks that threaten to make bureaucratic red tape run for money.

Information security is no exception. Hired as expert counsel, advisory, and management layers, we are expected to advise and guide in a comprehensive manner, covering as many layers as there are.

This is not only baffling at times, but back-breaking.

Then why do it?

For the promise given by the central government to citizens on every piece of paper they count as currency.

I promise to pay the bearer the sum of ....

This promise is why the control functions were designed and mandated by the regulator (RBI). This promise is why you exist.

Remember this promise the next time you audit or assess the risk of any aspect of country's financial infrastructure. That finding or risk would be your contribution to the nation.

Remember this the next time you get bored of your job.

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

So, this happened.

I spoke at a CPE (Continuous Professional Education) session on WAF (Web Application Firewall), its working, and some considerations around its audit and risk assessment (in other words, what to consider if you are to audit or assess risks around WAF).

Here's the PDF of the session. Credit to the original authors for the images used.

https://sripati.gumroad.com/l/qgblzj

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

Welcome everyone, to another edition of 'Risky Context'. This is the weekly dose for pentesters, auditors, and risk assessors in the world of security. Don't forget to subscribe and share this newsletter.

Incidents/ Write-ups

1. James Berthoty has collated details on the tj-actions/changed-files supply chain attack and put them in a structured manner. Brings home the point to pay/ donate for open source if you use them. The repo in question was maintained by one person who's received only few donations. This, considering the fact that the action was used by over 23,000 repositories. This is not sustainable. Read the blog for more details. StepSecurity also wrote about itand made their github action free for all. However, the original github action is free of the malware as well. In addition, Swastik Mukherjee has written succinct notes about the compromised GitHub Action as a LinkedIn post.

2. Notes on ByBit cryptocurrency heist

   1. By Vaughan Shanks in his LinkedIn post. He has listed various sources for his notes, including Mandiant report, in-depth analysis by NCC group. Good read.

   2. By Gal Nagli (Wiz staff, also happens to be a world class bug bounty hunter), as a LinkedIn post. He refers to a blog post, that he has written along with few other contributors. Worth a read.

3. Renee Bos writes about a case of 'Shadow AI', on LinkedIn. A Disney employee who downloads an AI tool from GitHub, giving cyber-criminals access to his password manager. More info - WSJ Tech Briefing Podcast episode, Futurism post

On AI

1. Linas Beliunas writes about zippy, the robotic chef, who is trained to cook Michelin-quality dishes. Best part, it costs USD 12/hr. His LinkedIn post

2. Novo Nordisk apparently has started using AI to draft clinical study reports. Paywalled article here.

3. Bureaucrats have also started using AI. Seems a natural order of things, considering boss' order to use AI more to increase efficiency. Now that AI generates, consults, and advise for policies, what's next - state sponsored AI poisoning?

4. Roberto Rodriguez, in his blog-post, shares his journey of building an AI agentic workflow engine with open source framework, Dapr.

5. Anthropic CEO talks about AI and its future on an episode of Hard Fork. Worth listening.

6. Christian Zot has generated a 50-point checklist to test nginx, using AI. While some items are applicable for almost all web servers, many points are specific to nginx. Have a read.

Thought provoking posts

1. Arstechnica reports that from March 28, 2025, everything you say to Amazon echo devices will be sent to Amazon. Kathy Reid, says, in her LinkedIn post

This means everything you say in your home - your domestic environment - is sent to a corporate whose goal is to generate revenue from that speech data.

2. James Berthoty writes a great post on his blog about how firewall vendors like CheckPoint and PaloAlto have stopped fighting for their share of CNAPP pie and have moved on to AI. worth reading.

3. Sygnia has published their field report for 2025, based on their incident response investigations throughout 2024. Worth a read.

4. Sandeep Wawdanehas written a blog post, highlighting NFC intent vulnerabilities in android apps. He has also built an app to help test these issues firsthand.

Tools

1. Formatify - a BurpSuite request converter extension, created by Siddharth Joshi. Instantly converts HTTP requests into multiple formats like cURL, python, powershell, and more. Get it here.

2. ExportHunter - Created by Bhargav Gajera for testing exported android activities. One can generate and launch APK to call activities with bundles, without using ADB or Android Studio. Saves ton of time. His LinkedIn post, tool link.

3. Matt Adams, creator of StrideGPT, released an LLM threat modeling benchmark, TMBench. Here's what he has to say about it (excerpts from 'about' page of the benchmark)

   1. ...My mission with TM-Bench is to provide an open, transparent benchmark for evaluating and improving LLM-based threat modeling capabilities. I believe that rigorous evaluation is essential for responsible AI deployment in security contexts...

   2. ...TM-Bench is the first benchmark in the world to evaluate the capability of Large Language Models for threat modeling. While other benchmarks exist for general AI capabilities or even some security tasks, TM-Bench is uniquely focused on the complex task of identifying security threats in system designs...

4. Hashcat is an excellent tool for cracking hashed passwords. However, I haven't met anyone who remembers hash numbers for all hash types. Jonathan Hodgson has written a blog post on how he used FZF (a fuzzy finder for command line) along with awk and sed to create a shortcut (work on bash and zsh) that simply works. Head over to the excellent piece.

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

I am a top-down guy. I made lot of mistakes. I learnt from my mistakes, my website and this newsletter is a reflection of them.

I hope you like it. Not my mistakes, but the learnings.

This edition summarises a series of articles from my blog "Risky Context" on various aspects of cybersecurity careers.

Enjoy.

Offense vs. Defense (https://sripati.info/offense-is-not-sexiest-defense-is/):

1. Glamour doesn't equal value: While offensive security roles like penetration testing or bug bounty hunting often hold a "glamour quotient," defensive security is equally crucial.

2. Leveraging existing skills: System and network administrators transitioning to cybersecurity can leverage their expertise effectively in defensive roles like threat hunting or SOC analysis.

3. Understanding "why cybersecurity?": Choosing a career path (offense or defense) should be driven by genuine interest and a clear understanding of "why cybersecurity," ensuring long-term motivation and success.

Top-down vs. Bottoms-up Thinkers (https://sripati.info/it-matters-in-cybersecurity-if-you-are-a-top-down-or-bottoms-up-person/):

1. Different approaches to learning and problem-solving: Cybersecurity professionals can be categorised as top-down (systems-level thinkers) or bottom-up (preferring hands-on learning) learners.

2. Career paths aligned with thinking style: Recognizing your thinking style is crucial for choosing a fulfilling career path. Top-down thinkers thrive in roles like auditors, risk assessors, and architects, while bottom-up thinkers excel as security testers, programmers, and bug bounty hunters.

3. Bridging the gap: While individuals naturally gravitate towards one style, it's possible to develop skills in the other, albeit with additional effort and time. A penetration tester moving to an auditing role will need to learn risk assessment and reporting, while an auditor transitioning to penetration testing will need to acquire technical skills and methodologies.

Cybersecurity Job Descriptions and Expectations:

https://sripati.info/on-cocktail-jds-in-infosec-and-why-they-will-keep-coming/

1. Cocktail JDs: The cybersecurity industry is characterized by "cocktail JDs" that combine diverse skill requirements due to security being a cost center and companies seeking to maximize ROI on their hires.

2. Bridging the gap between GRC and technical skills: While GRC professionals focus on strategic and governance aspects, having hands-on technical experience enhances their effectiveness. Understanding tools and processes allows for better documentation, risk identification, and audit performance.

https://sripati.info/please-don-t-kill-your-ciso-if-he-doesn-t-know-how-a-virus-works/

1. The evolving CISO role: The CISO role demands a balance of management and technical expertise. While deep technical knowledge like understanding how a virus works might not be necessary, understanding the team's technical explanations is crucial for effective decision-making.

2. Certifications as enablers, not guarantees: Certifications like CISA and CISM provide valuable knowledge but don't automatically translate to competency. Continuous learning, practical experience, and the ability to apply knowledge are essential.

The Realities of a Cybersecurity Career:

https://sripati.info/risks-of-a-cybersecurity-career/

1. Burnout risk: The dynamic and demanding nature of cybersecurity makes burnout a real risk. Juggling multiple tasks and constant learning can take a toll on mental and physical health.

2. Importance of "why cybersecurity?": Having a strong "why" is essential for navigating challenges and staying motivated. Understanding your motivations helps you persevere through difficult phases and achieve success.

3. A day in a pen-tester's life: Beyond the technical aspects of penetration testing, the role involves significant planning, coordination, reporting, and client communication. https://sripati.info/a-day-in-a-pen-tester-s-life/

4. Security as a cost centre: Recognising that security is often viewed as a cost centre (except in companies providing security services) helps professionals navigate organisational dynamics and advocate for resources effectively. https://sripati.info/security-is-a-cost-centre/

Key Quotes:

1. "While offense is glamorous, defense is better." ("Offense is not the sexiest game in town, defense is...")

2. "Knowing your thinking and learning process (top-down or bottoms-up) is crucial in general, but it takes center-stage when you mull over a career switch." ("Are you a top-down or bottoms-up person? It will matter while switching career in cybersecurity")

3. "What is invisible (individual needs, desires, and greed) will always drive what is visible (JDs, compensation, market preferences in infosec hiring and purchases, etc.)." ("On cocktail JDs in infosec and why they will keep coming...")

4. "Burn-out is real, more so in cybersecurity." ("Risks of a cybersecurity career")

5. "That “why” will be the only thing that could guide you from darkness to light, from “being naked” to “running naked with eureka”." ("Risks of a cybersecurity career").

So that's all for this week. See you next week, with some more articles. Please consider subscribing to this newsletter. Being member on my website will get you these articles as soon as I publish them.

So, I bit the bullet. Here I am, with my selected articles, in the form of a newsletter. While this will be a weekly newsletter, all of my articles are available on my website. Subscribers on my website will get my articles immediately, as I publish them.

I am a top-down guy. I made lot of mistakes. I learnt from my mistakes, my website and this newsletter is a reflection of them.

I hope you like it. Not my mistakes, but the learnings.

The first edition is about things that no course on pen testing will teach. Well, maybe some (like reporting), but not all of them.

I was fortunate to work with extremely talented penetration testers. Here's what I learnt.

Penetration testing will be affected a lot by AI, in coming years. Run of the mill testing will be done by AI, eventually. I am sure it is learning from all those test cases, payloads, and reports that are available publicly.

The articles in this newsletter emphasise that a successful penetration testing career requires more than just technical prowess. It requires a business-minded approach, strong communication skills, and a willingness to contribute to the broader goals of the organisation.

1. Penetration testing is not just about technical skills. While technical expertise is crucial, it's only one piece of the puzzle. Businesses view penetration testers as part of a larger ecosystem, requiring them to contribute to non-technical aspects like marketing, sales, and project management. Supporting business functions beyond penetration testing is crucial for career growth. By understanding and contributing to other business functions, penetration testers can become more well-rounded professionals, improve their career prospects, and gain a better understanding of the industry as a whole.

2. Penetration testers are valuable assets but need to be profitable. Businesses operate on a profit-loss model. Just like jumbo jets are expensive when grounded, penetration testers need to be actively engaged in projects to justify their cost. This means contributing to activities beyond just penetration testing, such as mentoring, writing articles, or developing tools.

3. Understanding the bigger picture is essential. A successful penetration tester needs to understand the business context of their work, including client expectations, regulatory requirements, and the impact of their findings. This includes recognising that not all customers prioritise achieving domain admin status, and some may prioritise risk assessment over vulnerability identification.

4. Moving from 'vulnerability' to 'risk'. Clients are ultimately concerned with the risks associated with vulnerabilities, not just the vulnerabilities themselves. Penetration testers who can effectively assess and communicate risk provide more value to clients and are more likely to secure repeat business. This involves understanding and contributing to all stages of a security assessment project, from marketing and sales to reporting and project closure. This holistic approach leads to a more nuanced and effective service delivery.

So that's all for this week. See you next week, with some more articles. Please consider subscribing to this newsletter. Being member on my website will get you these articles as soon as I publish them.

What’s integration? Here’s one (very rough, high level and extremely simplified) example from FMCG (Fast Moving Consumer Goods) industry.

Every finished product is dependent on some raw materials. Raw materials are bought (from other suppliers), processed, packaged as a product, and then sold.

When a business (that, till now, had focused on just selling the product) starts producing the raw materials required for the product, you can say that it is integrated.

Now onto testing (security assessment).

Here are the various activities that happen before (assessment): -

1. marketing assessment services

2. meeting potential customers, pitching assessment services

3. preparing and submitting proposals (to potential customers who ask for one)

4. plan for the assessment (scope, number of resources, who will do what, etc.)

5. execute the assessment

6. write the report

7. present the report, highlight major risks to customer infra, app, and data; answer any questions that the customer may have, defend your finding

8. project closure steps (store all assessment data into a secure location, remove customer information, add test cases to your repository, plan for a blog post on company portal, etc.).

Have you noticed (if you are still with me, that is) that assessment is only 1 among many activities done for a successful project?

Here’s another breakdown of the assessment activity.

1. identify vulnerabilities

2. prepare exploit(s)

3. exploit

4. assess the risk (what’s the impact when the vulnerability is exploited in the current environment, not just any environment).

5. document the risk appropriately.

What does it mean? Customers don’t pay to know about vulnerabilities that lurk in their infrastructure or app. They want to know about the risk that is inherent in their infrastructure or app.

Most of testers don’t want to assess risk. Reasons range from 'don’t know how to do so' to 'expectations must align with payment'. 

There is huge value in knowing how to do all activities. 

1. It makes you more aware about how each step affects those before and after it, which will bring more nuance to your delivery, and

2. The skill will affect the outcome (from ‘vulnerability’ to ‘risk’). Discussion on ‘vulnerability’ needs lots of explanation to management. In contrast, management understand ‘risk’ (hint: risk management is what business is all about).

3. Eventually, all this results in a satisfied customer, which usually results in more money, down the line.

Happy customer, repeat customer, more business, good referral, etc.

Strive to be a fully-integrated security assessor, not just a tester.

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

You need to get customer requirements clear. Are they ‘ok’ if you become a domain admin?

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

This is part of a series of posts, first one here.

As mentioned in one of my previous posts, a pentester is a critical, but one of the many, part in the overall business.

It also means that all those business parts (recruiter, marketing, sales, pre-sales, project management, project lead, etc.) always need some inputs from pentester. Those inputs not only make their lives easier, but also helps them perform better. And, they appreciate your contribution which helps you during ‘appraisal time’. Everyone wins.

If you, as a pentester, support them, it will help you in your career (not just in one-off appraisal).

Let’s examine how.

Contributing to other allied functions within will help you grow into a better team player, who understands what everyone brings to the table, and can contribute to it as well.

Makes you a juicier candidate (than others), in the job and while looking for the job.

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

...profitable only when on-air, expensive when in hanger.

This is part of a series of posts, first one here.

Here’s one way of looking at flow of money in a company (this is a simplified scenario, actual accounting is more complex): -

1. Company bids for and wins a project.

2. A team is allocated to work on the project.

3. For the entire time that the team is working on the project, their salaries, cost of the tool used, any logistical costs incurred, etc. are earmarked as ‘expenses’ towards that project.

4. After the work is done, invoices are raised to the customer.

5. When customer pays against the invoices, company books the payment as ‘revenue’.

In a business, every hire has to be useful and contribute to the business in one way or the other.

Pen-testers are useful when they are deployed on a project. That’s when pen-tester’s salary is offset against invoices raised on projects (salaries are one of the biggest entries under ‘opex’ heading in a balance sheet).

It is a red flag when you are not involved in any project or not doing any pentesting for your company. Here’s how it will unfold: -

1. During business reviews (how much we earned, what are the expenses, whats our profit pre and post EBITDA, etc.), performance of each business unit (BU) is presented.

2. If security assessment BU is not performing, additional questions are asked.

While this happens at top management layer, middle management also has their internal reviews. In these internal reviews, each project is reviewed.

1. If a project has more resources than planned, it gets questioned.

2. If a project is incurring more cost than planned, it gets scrutinised in detail.

3. If a project has not raised any invoice, since its start, it gets scrutinised.

In a security assessment company, pentesters are among the highest-paid techies apart from the business executives, of course.

The closer you are to business, higher will be the payout.

When the company performs, you will be praised for your contributions. When company doesn’t perform well, every one’s contributions will be reviewed and re-aligned.

So, ensure that you are always involved and contribute to the business. You can do so by,

1. pentesting for a customer,

2. preparing reports for more than one pentest,

3. mentoring junior pentesters, 

4. writing articles on company blog, 

5. submitting cfp for a conference, 

6. actually speaking in a conference, 

7. working towards releasing a tool that helps company in pentesting project, etc.) that helps your company execute pentest faster and better.

Strive to be useful at all times. 

I believe we all suffer from Parashurama’s curse to Karna. I believe it is so because we all are slowly turning into Karna (believing we don’t get our fair share, then lying to get ahead in life, doing all sorts of bad things in name of friendship, etc.). But I digress.

Bottom line - You won’t remember all your contributions when needed (aka ‘appraisal time’). So, keep a journal of all the times that you proved ‘useful’ to your company.

While down-time is required, nothing beats usefulness. 

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

Penetration testing (and security assessments in general) has evolved a lot in the last decade or so. At the same time, the underlying expectations of customers and business (that has hired the tester) has changed as well. This has lot of impact on a penetration tester's career.

What is this about?

This is about the other side of the fence. The non-pen-testing activities in a pen-testing company, why are they required, and where do you (the pen-tester) fit in. I hope that it helps you understand the big-picture (if there is such a picture) better.

To be fair, I don’t think I am the only one with these thoughts. Experienced pen-testers may already have seen all of these. However, I also think that lot of other pen-testers and wannabe testers won’t know about these.

And, you need to know.

So, here they are.

1. You are one cog in the wheel.

2. To business, pen-testers are jumbo jets.

3. Business will expect you to support them in non-pen-testing activities.

4. There will be customers who wouldn’t want you to become domain admin.

5. Reporting and soft skills are under-rated [in penetration tests].

6. There is value in becoming a fully-integrated tester.

7. You can pivot to these areas [from pen-testing]

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

… a very important one, but few more are needed before a business takes off and money starts rolling in.

This is first in the 'things no pen-testing course will teach you' series. Here's the introductory post.

A pen-testing (or security assessment) business needs to make money, like all other businesses. A pen-tester is a very important part of that business, but not the only important part.

The other important parts of business are the following people with the below skills (Simplified for brevity, please don’t nitpick):- 

1. Ability to convince people to give you a chance

   1. Marketing - Ability to make right noises so that market takes notice of your presence

   2. Sales - Ability to meet prospective customers, pitch your services

   3. Pre-Sales - Ability to write a kick-ass proposal that sells your services, with enough details to convince a customer to hire your company (pre-sales)

2. Project Manager - Ability to plan, schedule, and divide pen-testers for each assessment.

   1. A pen-testing business needs pen-testing projects.

   2. With each project, comes need of pen-testers.

   3. Multiple projects run in a pen-testing company, at any point in time. Which means, 

   4. If you don’t plan the projects properly, 

      1. you may not have pen-tester available for upcoming projects,

      2. you may put less pen-testers for a project that require more,

      3. you may put more pen-testers for a project that doesn’t need as many,

      4. you may not know whether you need to hire more pen-testers or let few go (as you are not getting any more projects).

3. Project Lead - Ability to create presentations conveying your findings to variety of customers at client business (yes, there are more than one type of customer in each company that you pen-test. More about that later).

4. Finance or Accounting - Ability to measure whether the (pen-testing) business is gaining money, or losing it. Without this ability, you won’t know whether you are growing, or shrinking.

5. Recruiters - Ability to identify talented pen-testers and to assist in the overall hiring process.

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

No, it is not bigger team, corner office, or that new tool promising to remove all your infosec worries.

Get read-only access on all network devices in the company (switches, routers, firewall, etc.).

Not for yourself, but for your team.

Do I hear a ‘why’? glad you asked.

Network is the nerve centre of a company. Access to the networking devices (switch, router, network firewall) will help the security team understand, among other things,

1. Segmentation (how is the network divided? Do we have a DMZ? Is it empty? Are all servers in one part of the network or sprinkled across town?, etc.)

2. VPN configurations (is the VPN configuration same across all firewalls? Are there any users who are present on all firewalls? Do all VPN users have mac binding, MFA, integration with NAC? are any VPN users exempted? etc.)

3. Access control (TACACS, Radius, local accounts, password policies - or lack thereof, etc.)

4. Traffic flow (allowed/ denied) - which part of network can talk to every other part? Which part of network is isolated?

5. Network pathways associated with critical assets,

6. End of sale, end of services, etc.

The access will also help you answer some crucial questions

1. Whether any new asset added to the network?

2. What are the network pathways open to your critical assets?

3. Which ports are allowed on your critical assets?

4. Whether 2FA is configured with VPN?

5. Whether 1 user ID is duplicated on multiple firewalls with same configuration (e.g., 2FA)?, etc.

As a CISO, you must ask for this access.

Use all your goodwill, charm, and pull to have this access. It will pay good dividend.

However, a tool is only as good as the person wielding it. You will get administrators for the tool, but you will need someone who could identify security risks while going through the data provided by the tool.

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

Important disclaimer - it is very important that you vet the report template with the customer before you start the engagement. It is important so that they can suggest any changes ahead of the chaos.

So here are the most important elements of a pentest report, in that order,

Introduction

1. 1. What is this document

   2. How to read this report

Here's an example.

Executive summary

1. 1. you get two types of customers in every engagement. One who implements your recommendation, and another one who pays for the pentest. This summary is for the one who pays. Make it count.

   2. kill chain/ attack-narrative Infographic, key risks, impact, high level recommendations, potential timelines (if possible).

   3. Leaders want to know the key risks and the exposure (e.g., potential fine from regulator, reputation risk, risk of non-compliance, etc.).

   4. with each key risk, link all different vulnerabilities that are part of that risk

   5. No details, but lot of references to locations (in the current report) where the finding is detailed.

   6. It will be better if this part of report is printed and hand-delivered to the customer.

Table of Findings

usual suspects to go here (#, ID, title, small description with impact, risk rating, reference to the location in current document). Here's an example.

Detailed Findings

Some ppl include attack narratives here, others add one table per finding, divided by severity/ risk levels. At the minimum, each finding should have the following fields

1. 1. finding ID (also see 'table of findings' above).

   2. severity/ risk

   3. finding title (should combine vulnerability and impact)

   4. finding details (should explain vulnerability, impact, and justification for severity/ risk rating)

   5. remediation

   6. other info for compliance purposes (e.g., CWE ID, any CVE ID, OWASP TOP-10/ ASVS/ Testing Guide reference). Many regulations expect this information to be present for each vulnerability. Not including this information may result in an audit finding.

Scope, Methodology

why is this at the end?

1. 1. Becoz it doesn’t matter much, at least for the report. It is discussed, agreed upon, and approved much prior to the report. It is kept in report for record purposes and for the first type of customer (refer executive summary).

   2. Sure, someone may want to check the coverage. However, overall, the most important items for customer are already described above.

Other relevant Annexure

1. Output from automated tools like Nessus, nmap, burp suite, sqlmap, etc.

2. Criteria for severity/ risk ratings (why a vulnerability/ risk is 'high', 'medium', or 'low', etc.)

Some elements that I have not included here, but are assumed to be present, are: -

1. Cover page, logo,

2. document title, client name (name, email ID of the point of contact)

3. document control (who created/ when, who approved/ when, change tracker)

4. vendor contact details

Additional Guidance

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

I see lot of opinion and feedback on JDs that ask for hands-on experience for a leadership role in infosec or a cocktail of administration experience.

I don’t think they will stop anytime soon. I think they will keep coming for quite some time. Here's why.

1. InfoSec is a cost centre for almost every company, except in a firm that provides it as a service.

2. Due to the many dimensions that infosec has branched into myriad set of skills are required if a firm wants to keep themselves secure from all threats (penetration testing, soc, threat hunting, administration of security tools, etc.).

3. Due to point 1, companies want to maximise their return on investment (employee salaries are a major opex item).

4. The first hire in any new department/ function is always the leader. The leader is then expected to hire, train, and utilise the optimal resources (read - at as minimum a cost as possible, without hurting the company) to achieve desired outcome. Hence the rise of outsourcing of many security activities.

5. Information security, as a career and industry, is still evolving. Employers are still trying to figure whether they need such a function in-house (cue - rise of MSSP and vCISO), whether the position of CISO really deserves a seat at the table, do they need a CISO (a strategic advisor) or Head of Infosec (more hands on administration and involvement), etc.

6. Due to points 3, 4, and 5, the employers try to cram as many skills and experience requirements as they can, into a JD.

That, is the reason why you see so many mixed JDs (CISO requiring 5 years of C++ development experience, looking for significant IT experience for a junior role, etc.) in infosec.

However, is this situation bad enough to warrant a rant?

Let’s take a cocktail JD as example - administration experience as a requirement for a GRC role.

Not every company has use for a GRC professional full-time. Companies want (and need) governance and strategic infosec advice, but they also need people who can implement them. These are in a very short supply.

Our understanding of GRC is different from that of an employer. For many of those, it involves

1. Documentation (processes, SoP, position papers, project plans, ToR, RFP),

2. Coordination (interfacing with other departments; facilitating people who are 2-3 layers deep on infosec issues, why you want them to do the work, what is it that you exactly want them to do, facing audits, getting the findings closed, etc.),

3. Project management, with activities that are 2-layers deep at each step.

We think 'strategy', they see 'documentation'.

We think 'security program management', they see 'someone who will do all jobs related to security, including driving a security program'.

Add to it the following facts,

1. We are at odds with all other disciplines in a company (we are in our infancy, industry is still figuring out how to treat us and where to put us in the org chart),

2. Most of GRC work is hard to prove (unless the process yields tangible benefits or stakeholder delight), and

3. Most of the us as practitioners are not doing a good job of making employers aware of the nuances and challenges of their role, and the value they can bring except by way of a lament/ rant.

I have said before that you don't need administrative certifications when your aim is to understand how-something-works-so-that-you-can-break-it. However, some level of hands-on experience is an advantage that you don't want to miss on. Hands-on experience on technology is a boost to GRC activities.

My GRC skills improved drastically, once I spent time on tools.

1. I could write better processes that aligned with the environment (rather than advising industry best practices), perform a security audit better, identify more risks in the environment than before, understand a regulatory advice and suggest a better way forward than ‘best practices’, etc.

2. I could identify serious findings in a ticketing solution because I spent some time with the tool.

3. I could suggest a patch management process that utilised the current tool and manpower better due to my familiarity with their tech stack, my understanding of the way patching works there.

So, I think we will continue to see the cocktail JDs in InfoSec for some more time.

What is invisible (individual needs, desires, and greed) will always drive what is visible (JDs, compensation, market preferences in infosec hiring and purchases, etc.).

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

I see lot of people aiming at getting administrative certifications (e.g., CCNA, CCNP, Microsoft Certification exams, etc.), when they aim to become a penetration tester.I have spent quite some time with penetration testers and have noticed that this approach has its own perils.I have tried to list them here, have a read.

The problem

Strong foundations are important to become a penetration tester.
Often, certification study guides (e.g.,those for CCNA, Network+, Security+, etc.) are prescribed to learn the basics.
Nothing wrong in getting certified, along the way, is it?

However, we end up missing forest for trees.

I assume you want to become a pentester

A Pentester breaks into things (systems, networks, web applications, mobile apps, IoT, lateset-fad-here).

In order to do so, a Pentester needs 3 crucial skills

The 3 crucial skills to become a pentester

1. An understanding of how things work (so that they can be broken into). One needs to constantly keep learning to do so.

2. An eye to look at a system (IT asset, process, workflow, etc.) and to identify the weak points.

3. Willpower to keep moving when you are stuck and not leave the field.

While it is important to understand how a network works (CCNA) and how it is secured (CCNP), I believe trying for these certifications is a waste of time, if pen testing is your goal. Here's why...

1. Humans are builders first.

2. Breaking things doesn't come naturally to us.

3. The administrative certifications are all builder/ maintainer certs. They primarily teach 'how something works', not 'how to break it'.

Now consider this.

1. A Pentester's job is getting tougher by day. Hardened networks/ applications, evolving firewalls, shrinking budgets, make job very difficult for a pentester.

2. As a pentester, you will be required to learn 'how to break into this thing' on a daily basis.

3. The key question should not be 'how does this work?' but 'how to break it?'

4. More often, we focus more on the first question, forgetting the second one.

5. However, it does not mean you stop learning things (you won't be a better pentester unless you learn how things work).

6. What it means is this...

Keep the second question in mind (how to break it) while looking for answer to first question (how this works).

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

Never thought this would happen.

Neelu Tripathy is a wonderful podcast host.

She not only put a first-timer guest (me, the clueless) at ease, she also prodded me with thoughtful questions. I wondered if she felt like pulling teeth. Very graceful and prepared host, though.

I am grateful for the opportunity and enjoyed my time as a guest.

I spoke about ISO 27001, it’s a standard I like a lot.I also spoke about usual challenges during implementation, and some ways to address them.Please listen to it, ignore my hand gestures, and let me know what you think of it.

Sign up for Risky Context

I write at the intersection of pentest, auditing, risk management and career advice. I add context to the infosec risk. I help answer the question 'where is the risk?'

Subscribe

No spam. Unsubscribe anytime. Musings based on real experiences, not theory. All Infosec, mashed up.

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

These clauses and covenants must be part of your Service Level Agreements (SLA) with service providers.

There are few parties while any enterprise application is bought for use within a company. They are: -

1. User Department - End-users for the application. May or may not contribute to budget (to buy the application).

2. IT - Budget to buy the application usually comes from this department. IT also helps in providing overall technical support in evaluating, procuring, deployment, maintenance, and support (on behalf of the customer).

3. InfoSec - In regulated entities, this function is responsible to say 'go ahead and deploy it in production environment. It is safe to use, relevant controls are implemented to address any adversary exploiting any security weaknesses in this application and hurting us'.

4. OEM (Original Equipment Manufacturer) - A term used to describe both hardware and software providers. People who create them.

5. System Integrators (SI) - The company who helps in buying, implementing, maintaining, and supporting the application.

A basic premise - right of a customer to have a bug-free and secure application/ service delivery.

A covenant in legal term refers to a promise made by one party to another to either do or refrain from doing a certain act.

As a customer, it is our right to be able to use a secure and bug-free experience. Vendors must strive for it. As a consequence, they must not charge their customers for fixing bugs or security vulnerabilities.

What if this clause or covenant is not present in your agreements with the vendor or SI (System Integrator) of the enterprise software? They may seek compensation for fixing bugs or security vulnerabilities! This will cost your company by increased OPEX (Operating Expenditure). CFO won't be pleased.

Ask your application vendor/ System integrator to help integrating logs from the system to your SOC/ SIEM. You will have lot of difficulty in doing so, without their help.

Ideally, all security related logs from your IT tools should come to your SOC.
This is important so that SOC team is alerted when any anomaly happens.

HelpDesk/ Ticketing systems, business critical applications (Core Banking Systems, CRM, Enterprise Content Management Systems, version control systems, etc. are some examples of such tools.

There is a catch, however.

Someone needs to figure out those security logs (their construct, the most important security events from these tools and the type of logs that indicate those events) and prepare use-cases and alerts for them. your SOC will be a tooth-less tiger, otherwise.

Your SOC team will know how the SOC and associated tools work, they know how to collect the log, how to create use-cases and alerts. They will also know about logging capabilities of most of IT tools, e.g., firewall, IDS/ IPS, etc.

However, they won't always know which security events are logged by third party applications. They will need support from your SI (System Integrator)/ OEM (Original Equipment Manufacturer).

Your SI, while implementing the application for you, must help your SOC team to prepare appropriate use-cases. They may do so by making your SOC team aware of the what security events are being logged by the application, construct of the log, etc.

However, your SI/ OEM won't help you unless you make this activity, a part in their SoW/ SLA.

Make sure that you,

Put this activity in your SoW (while identifying proper SI for implementing your enterprise application), that you will need them to help your SOC team to create relevant use-cases and alerts. and,

add relevant clauses in your system integrator's contract.

Otherwise you won't get proper logs, nor will you be able to prepare appropriate use-cases/ configure alerts.

You will be sitting ducks when an attack happens on the application.

You also need to ensure that your SOC analysts fight alert-fatigue.

Security Operations Center (SOC) is an important part of any defensive infrastructure.

It is only natural to create alerts for use-cases that an organization deem important. However, alert fatigue could kick-in.

Alert fatigue happens when a soc analyst ends up looking at so many alerts, that his/ her ability to decide on a suitable action is hampered.

This puts the organisation at risk. The analyst may miss a crucial alert. However, the analyst didn't do it on purpose. he/ she just got fatigued by looking at so many alerts in a day.

So, what's the way out?

one trick could be to name your alerts so that they scream at you to pay attention. e.g., imagine an alert titled in the format below: -

'device control'-'your favourite AV'-'a removable storage device was inserted'

compared to the alert title below: -

'someone inserted a USB'

Which one screams at you? Which title doesn't need you to understand/ de-cipher the meaning?

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r

Investopedia defines a cost centre as a department/ function within a company that doesn't add to profits, but needs money to operate. e.g., human resources, accounting, admin/ housekeeping, etc.

They also define a profit centre (in the same page) as a function/ department that adds to profit by their actions. examples include sales, business development, activities directly related to a company's primary line of business, etc.

In most of the companies, information security is implemented because some regulation/ law/ customer asks for it, lest they lose their business/ customer. Companies whose shares are traded in public, banks, insurance companies, etc. are examples of some organisations that have some security related mandates to follow.

The only place where security is a profit centre is in a company that provides security services or products. In those companies, the function is directly related to their primary line of business.

It is a cost centre everywhere else.

Every CISO knows it, then why am I talking about it?

Because 'yad bhaavam, tad bhavati' (as the intention, so you shall be).

Later...

At the intersection of pentest, auditing, risk management and career advice. Musings based on real experiences, not theory. All infosec, mashed up.

‎Follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r