My Selected Posts

Some #chatgpt motivation for the weekend.

Become the #chatgpt of your domain or area of expertise. You should be able to provide articulate responses to many complex questions within few seconds, live. Needs a lot of reading and being updated continuously, not a easy feat to achieve.

Fully original post, I swear I did not take any help of any OpenAI platform 🙂

Follow me for less frequent/dramatic but original content and insights from the cyber security world.

#chatgpt #ai #generativeai technologies are revolutionary to business and there is no avoiding their usage of them somewhere in your business processes. Every industry and vertical that deals with some form of data, needs controls around the usage of these technologies and #dataprotection. Although, no one has a standard or best-practice solution yet, here are some considerations for their use at work.

*️⃣ Technical enforcement to control, restrict or monitor the consumption of these technologies won't be effective as it is not limited to work devices.

*️⃣ With a good intention of getting valuable insight or output from the generative AI technologies, one can accidentally share Intellectual property(which is unstructured, subjective, and hence difficult to categorize and flag for DLP and other pattern/regex or signature-based mechanisms. If you have come across any other ways to achieve this please share in the comments.

*️⃣ We need to understand the basics of these technologies and be able to articulate org-specific risks in plain buzzword-free language and include them in the awareness programs and day-to-day interactions.

*️⃣ Amend the Acceptable Use Policies to include the use of these technologies in tune with the industry-specific regulations, contractual obligations or compliance requirements.

*️⃣ Partner with your legal team to review the terms of use, end-user license, agreements, etc. So that you can get more clarity on technical and legal issues before the adoption of these technologies.

*️⃣ The productivity and development tools like code repositories that provide additional capabilities by integrating with the Generative AI platforms' APIs may have configurations to restrict specific information flows.


[#disclaimer : All opinions shared by me are the result of the aggregate years of experience, shared purely for the benefit of the community, and cannot be attributed to my current or previous employers, or the vendors I might have worked with]

Some inputs for sales professionals of #security #product #startups. Though Sales is not my domain by any stretch, I am compelled to share this from my own experience and that of my fellow colleagues in the security community, being on the receiving end several times.

Please don't chase every security leader with a direct cold sales pitch message, see them as micro extensions of your own customer success teams, the best chance to get direct feedback from the battlefield. I don't know how feasible that is considering the infamous skills gap, but security product companies should have at least some security practitioners in their Customer facing teams.

The sales reps need at least some practical exposure or in-depth training in the relevant security domain, not only specific to the product they are trying to sell. This is an absolute must if you are targeting a functional security leader, that way you can talk with minimum acronyms and buzzwords.

Someone had reached out to me a few months back with an offer to get paid some $$ amount just for attending a short demo/review of their product to collect the "feedback". I agreed to attend it without a single $ in return, considering the unique interesting features claimed on the website, although not needed by me or my org. That person kept a hard condition that I have to give some details about my org and myself in order to proceed, and eventually canceled the demo. In my opinion, this was a very good opportunity lost.

Thoughts? I hope I am not spamming you back folks :-)

This approach of automated deactivation of secrets taken by GitHub is certainly commendable to reduce the damage before it’s too late. However, the secrets, especially API Tokens/Keys may be spread not just in Code Repos but in many internal productivity/collaboration/Tracking tools mostly SaaS. It needs a multi-level approach, which I am trying to summarize below.

1] A secure, auditable yet accessible secrets storage solution that supports the entire lifecycle from creation and rotation to revocation. Easy to adapt and minimal impact to developer experience. The important factor here is having different namespaces and permissions for critical and non-critical secrets, e.g. Prod vs Non-Prod. Depending on the environment, there are many on-prem and cloud-native solutions available for this purpose.

2] Secret detection and alerting tool that can support various sources mentioned above for both hard-coded and internally leaked secrets. It should also highlight active the keys of well-known Cloud Service Providers to prioritize the remediation. There may be more but the only tool I could find with all these features is the enterprise version of #trufflehog by Truffle Security Co. I didn't mean to endorse the specific tool however had to bring this up considering the close relevance and unique features. It also supports hybrid architecture, internally hosted scanners send only the metadata of the secrets to a SaaS component for statistics and dashboards.

3] Automated features of #sast tools to prevent hard-coded secrets from entering the code repos, ideal would be the ones that integrate into IDE and notify the developers immediately. Again, like point 1] above, there are multiple tools available for this purpose.

4] The usually not externally exposed but highly critical component is IaC which may have high-privileged secrets with access to underlying deployment infrastructure, and often not feasible to have protections like MFA. Hence it needs to be brought under the same protections mentioned above. There are multiple tools available for this purpose too.

On a personal front, looking forward to meeting you in person at some event soon AMol NAik to learn from your vast experience of scaling the security of the modern workloads.

[#disclaimer : All opinions shared by me are the result of the aggregate years of experience, shared purely for the benefit of the community, and cannot be attributed to my current or previous employers, or the vendors I might have worked with]

Common issues and recommendations for #threatmodeling

1. Not contextual, time-consuming, blindly following the frameworks like STRIDE(it's a great framework, don't get me wrong), often in isolation for the sake of documentation and compliance.
Recommendation: a] The general guidance is to ask these questions, What is being built, what can go wrong, and what can be done about that? b] Do it at two levels, one comprehensive threat modeling for an entire product/service at once, and lightweight recurring once for new features and changes to existing ones.

2. Reps from Product Management, Architect, Technical Operations, and Security(GRC+SecOps) need to be involved. Why? Read below.

3. Outcome of #threatmodeling should be the list of controls along with the prioritization for implementation.
"Threat, Risk all that is fine" is NOT fine. It is important and should be brainstormed enough to make the risk scoring realistic by considering various aspects like technical, business priorities, data type & sensitivity(hence regulatory GDPR, PCI, HIPAA), Internet vs Internal facing, Integrations, and existing security controls. This realistic risk scoring will be the foundation of the decision-making process. It's always going to be a trade-off between Risk and Speed of delivery.

Risk Apettite of an Organization

Org-level Threat Profile should drive your risk management program and investments. At a high level, it's all about knowing your critical assets(with diverse threat profiles of their own), threat actors, and threat vectors. However, these apparently simple aspects are not easy to comprehend in today's hyper-connected ecosystem.

#informationsecurity #cybersecurity #devsecops #securebydesign #riskmanagement

#zerotrust is an approach, a north star. Not a process, technology, or security control to implement and mark as complete.

Also in the real world, it's a "variable trust" and not an absolute zero trust. And the trust should vary as per risk. If you blindly implement the fancy(and costly) product or architecture costing you more than the value of an asset being protected, then you are missing the whole point. A foundational security principle really, just rebranded within a glamorous name.

It is natural and becoming dominant in today's world filled with information overload, technological disruptions, buzzwords, and so-called Thought leaders and Influencers.

Let's embrace it instead of seeing it as some abnormality and connecting it to depression, anxiety, or self-esteem.

Self-doubt is at the core of it and most professionals experience it in various forms. It is a good indicator that you are taking a stock of your career/life and seeking meaningful and impactful work. Byte-sized learnings in the field of interest over a longer period of time is the way out of it. Let's leverage it to improve our careers and lives.


Also in the real world, it's a "variable trust" and not an absolute zero trust. And the trust should vary as per risk. If you blindly implement the fancy(and costly) product or architecture costing you more than the value of an asset being protected, then you are missing the whole point. A foundational security principle really, just rebranded within a glamorous name.