Ask HN: Any resources to understand the cybersecurity landscape?
Looking to find resources to understand the cybersecurity landscape, where and how the field is moving forward.
3 comments
Can you be more specific about what you're looking for, why, and what kind of background you have?
Cybersecurity is rather broad. Asking about the landscape is going to have significantly different meaning if you're studying to pen test in school versus being a new CEO and having a security responsibility towards your customers vs being a politician trying to create reasonable regulation.
Cybersecurity is rather broad. Asking about the landscape is going to have significantly different meaning if you're studying to pen test in school versus being a new CEO and having a security responsibility towards your customers vs being a politician trying to create reasonable regulation.
I wanted to develop an understanding of the market, where the industry is generally heading. To give some context, I am a software engineer typically spend time building enterprise software. I want to understand the landscape enough to be able to build a product (in the domain) on my own.
Modern security is all about enabling modern engineering and allowing them to go ask quickly as responsible. Responsible has always been a function of risk / risk profile, always defined as likelihood * impact.
Please don't build a security product without having any experience or validating any real problems. This is especially true in security, where not every potential problem gets prioritized and solved.
Please don't build a security product without having any experience or validating any real problems. This is especially true in security, where not every potential problem gets prioritized and solved.
I guess it's important to understand that security is political before its technical. This is because secutity is first and foremost a resource allocation problem. Alignment is towards spending the minimal amount possible on security. This means in order to buy a security product, it must promise to reduce financial exposure to breaches at a cost that is below the financial exposure. There is no moralizing here. There is only economics. Nobody cares what is right, people only optimize for what is cheapest. Cost includes engineer time spent patching security problems and the opportunity cost of that. Ignorance is often preferred. Incompetence is an easier defense than negligence. Most companies would jump at the chance to make someone else responsible/culpable for the consequences of poor security investment.
Most engineers, particularly people who work on infrastructure, are extremely wary of companies that make security promises. This is because the vast majority of security offerings are definitely security theater.
If you intend to do something in the realm of security theater, please don't, the harm is real. The harm is to your mother or your grandparents, your non technical friends. Please never engage in anything that does not actually improve security in a meaningful way, no matter how profitable it is, and it is most definitely profitable. There is a lot of snake oil in the industry.
The process of security is probably pretty close to:
Most of the security folks I know talk to eachother, follow security people on twitter, or follow people like krebs. There are many mailing lists for notifcation of major security problems, many are invite only. Hacker news is probably good enough to seeing industry shaping stories. If you want to do research mining the CVE database can tell you a lot about exploits. Security folks frequent conferences. Defcon is probably the most popularized but I don't think it's industry shaping.
I think the industry overall is often shaped by major public exploits. For a while SCADA systems were the big thing. Heartbleed showed us that many of the libraries we depend on are poor quality or neglected. Leftpad showed us that many systems we implicitly trust aren't trustable. Spectre showed us that both hardware/OS are not guaranteed secure and that part of security means understanding your hardware might become 20% less efficient overnight. Solarwinds showed us that supply chain security is much more important than we thought. Russia's invasion of Ukraine has put a little bit of focus back on nation state actors and securing critical infrastructure systems (like power stations and cell towers). Pegasus showed us that zero days are absolutely abused by powerful entities and your CEO's communications may well be compromised. Colonial pipeline was a big thing.
Frankly, if I were an investor, I would not trust a product dev who went from product right into making security solutions. I would expect a person creating security solutions to have worked in a security based role and then had a desire to generalize solutions or to solve a painful problem faced in that role that that all companies face.
Most engineers, particularly people who work on infrastructure, are extremely wary of companies that make security promises. This is because the vast majority of security offerings are definitely security theater.
If you intend to do something in the realm of security theater, please don't, the harm is real. The harm is to your mother or your grandparents, your non technical friends. Please never engage in anything that does not actually improve security in a meaningful way, no matter how profitable it is, and it is most definitely profitable. There is a lot of snake oil in the industry.
The process of security is probably pretty close to:
Identify what needs to be secured
Identify the cost of poor security (so you can beg leadership for resources)
Identify ways it can be attacked
Identify the cost of prevention
Prevent the things that need to be secured from being attacked successfully via technical measures
Set up systems to find Indicators of Compromise (IOCs) to verify you haven't been attacked
Set up systems such that when a compromise is indicated, the extent and method of penetration can be fully understood
Set up defense in depth such that you assume one system is completely compromised and defend the other systems from it
Sanity check your security posture via pen testing or bug bounty programs
Identify how your systems might be abused by bad faith actors
Set up systems to understand bad faith use of your systems
Create and implement prevention and remediation of bad faith use of your systems
Set up systems to audit employee usage of systems
Gather evidence and prepare it for law enforcement
Interact with law enforcement in regards to bad faith uses
Identify the compliances that you need
Identify acceptable solutions for those compliances (which are frequently bad faith)
Implement the solution to compliance requirements
Handle the business <> legal <> technical compliance relationship
Apply for and certify the compliance.
Understand
Prevent/Harden
Build/Monitor
Verify
Most of the security folks I know talk to eachother, follow security people on twitter, or follow people like krebs. There are many mailing lists for notifcation of major security problems, many are invite only. Hacker news is probably good enough to seeing industry shaping stories. If you want to do research mining the CVE database can tell you a lot about exploits. Security folks frequent conferences. Defcon is probably the most popularized but I don't think it's industry shaping.
I think the industry overall is often shaped by major public exploits. For a while SCADA systems were the big thing. Heartbleed showed us that many of the libraries we depend on are poor quality or neglected. Leftpad showed us that many systems we implicitly trust aren't trustable. Spectre showed us that both hardware/OS are not guaranteed secure and that part of security means understanding your hardware might become 20% less efficient overnight. Solarwinds showed us that supply chain security is much more important than we thought. Russia's invasion of Ukraine has put a little bit of focus back on nation state actors and securing critical infrastructure systems (like power stations and cell towers). Pegasus showed us that zero days are absolutely abused by powerful entities and your CEO's communications may well be compromised. Colonial pipeline was a big thing.
Frankly, if I were an investor, I would not trust a product dev who went from product right into making security solutions. I would expect a person creating security solutions to have worked in a security based role and then had a desire to generalize solutions or to solve a painful problem faced in that role that that all companies face.
Wow! I love you..
^^
A lot of security is kinda boring. Pentesters lament the writing of reports. Infrastructure security folks frequently end up working on operational problems more than security problems. Corporate security deals with phishing, account/permission management, and auditing what people do on their computers. Product security folks frequently respond to bug reports or have to walk engineers through how to rethink their goal or set up alerts on smelly code patterns and then teach the engineers how to correct them.
If you just want to explore the technical side of security devoid of business responsibilities, then CTFs are pretty great introduction: https://ctftime.org/
You can think of them as series of technical puzzles. After competitions are done, many teams will do a detailed write up so you can look at what techniques and tools they use. An above average college student at a good college might be able to do 1-3 problems per competition, so if you find them hard, you are in very good company.
picoCTF (https://picoctf.org/) put on by CMU, is probably the best one to start with. IIRC it's aimed at high school students and is much easier than most, so it is a great intro to CTFs and the "hacking" side of security in general.
CTFs are kind of learning about the security primitive of "exploit" as well as the following step which is "shellcode."
Corporate security is a lot more network, scanning, patching, and auditing focused. Learning/playing with metasploit and thinking about how to defend a machine someone hands you from it is probably where learning starts to get quite practical.
owasp is also good stuff: https://owasp.org/www-project-top-ten/
A lot of security is kinda boring. Pentesters lament the writing of reports. Infrastructure security folks frequently end up working on operational problems more than security problems. Corporate security deals with phishing, account/permission management, and auditing what people do on their computers. Product security folks frequently respond to bug reports or have to walk engineers through how to rethink their goal or set up alerts on smelly code patterns and then teach the engineers how to correct them.
If you just want to explore the technical side of security devoid of business responsibilities, then CTFs are pretty great introduction: https://ctftime.org/
You can think of them as series of technical puzzles. After competitions are done, many teams will do a detailed write up so you can look at what techniques and tools they use. An above average college student at a good college might be able to do 1-3 problems per competition, so if you find them hard, you are in very good company.
picoCTF (https://picoctf.org/) put on by CMU, is probably the best one to start with. IIRC it's aimed at high school students and is much easier than most, so it is a great intro to CTFs and the "hacking" side of security in general.
CTFs are kind of learning about the security primitive of "exploit" as well as the following step which is "shellcode."
Corporate security is a lot more network, scanning, patching, and auditing focused. Learning/playing with metasploit and thinking about how to defend a machine someone hands you from it is probably where learning starts to get quite practical.
owasp is also good stuff: https://owasp.org/www-project-top-ten/
Good resource (if you like visual learning):
https://www.youtube.com/MalwareTechBlog
https://www.youtube.com/MalwareTechBlog
latacora's blog
owasp cheatsheets
owasp cheatsheets