Flush times for hackers in booming cyber security job market
reuters.com
reuters.com
Defensive security is a cost center without clear, deterministic metrics for success. Let's say you pay X on defensive security (which is an oversimplification when you're talking about a cultural change, but that cultural change involves people learning how to pay attention to security, and paying attention is a form of man-hours, for which a cost can be calculated). If you don't get attacked, is it because the X you paid is high enough to deter/foil attackers, or could you have paid less and achieved the same result? If you are attacked and the attackers get past your defenses, is it because the X you paid wasn't enough, or if you had spent more, would the attackers have succeeded anyway, because of their relative power and motivation? For defensive security, it's very, very hard to justify to bean counters that X was the correct amount of money spend, no matter what the real outcome is, because it's hard to understand X's affect on that outcome.
Pentests which result in tickets/issues/etc. are much easier to justify. The company spent X on the pentest, and it got Y feedback in return. Simple, and effective, at least in the short-term.
It's part of the overall challenge that organizations face when they become metrics-driven. People choose the path of least resistance, so if you ask people to measure data, they'll measure the data that's easiest to measure. Data that's harder to measure - culture and social attitudes - becomes "not a priority" to measure.
Unfortunately I am not sure if currently consumers care that much about security of their products relative to convenience, price, and eye candy.
But in theory those who spend lots on red side will end up having a more expensive product and a bad reputation, so perhaps investing more on blue will win in the long run.
"Regular pen test" is seen as demonstrating security, which is as little perverse because the results don't typically get published so you could be having the same issues year after year and look just as good as someone who gets a clean bill each time.
then the other teams only handle requests from the ios app they own, and red team finds tons of amateur attacks that work. they spend a quarter fixing it, and boast that they worked with the red team to patch hundreds of vulnerabilities. and everyone is promoted.
but that is not new. it always happened with teams that causes outages, or teams that miss out obvious revenues stream for years. remedial action for some reason is always rewarded in troubled big corps.
>for some reason
I would go out on a limb to say it's definitional. A troubled Big Corp is troubled precisely because it focuses on the wrong thing.
We discover after a while that another company gets a contract 10x our price fixing the issues we discovered
If they make up a bunch of minor things that don't matter, you can ignore those and focus on the important ones. I suppose if you don't have any in-house expertise at all to evaluate what they say, the conflict would be more important?
You'll see this in almost every situation that is somehow related to auditing.
My experience is limited to security software development in e-banking, e-commerce, network security and data security domains in technology areas like cryptography, PKI, deep packet inspection, and network protocols. I know my experience may not be representative of the entire security industry and there is a possible selection bias too (i.e. I may have seen more demand for blue team engineers because I have belonged to blue teams myself), but I thought I should share my experience here to present the other side of the story.
I think there needs to be greater punishment for companies that lose customer information. Only then will the incentives be large enough for something to be done.
We had the Red team come in and while pentesting share his screen with us all. Another Red team member explained what he was doing and after an attack was launched and we would see if our tools detected the activity. If they didn't, we went out to find out why. This was huge. It showed us where we needed to tune some things and where we needed newer and/or different tools.
This isn't the only way we get pen tested. They do their annual "regular" pentest. The Purple team thing was awesome though. We learned a ton. Since I happen to own most of our tools and am secondary on the ones I don't own, I have learned a tremendous amount and I've been in IT for 20 years.
> results in internal tickets/issues/BUGs, while the development/operation practices are kept the same.
You could not be more accurate; this also applies to groups that maybe started out as corporate infosec (virus protection, simple application scanning, etc...) and were never really tightly coupled with engineering. We have identified essentially identical authorization issues in a pre-release version of one of our products two or three times this year, which was also present in the last 3rd party pentest of the same product before my time (which was pretty scathing). Its incredible.
1. Compromise is inevitable 2. Default-allow products always fail 3. 1 and 2 are not opinion or marketing spin, just simple truths 4. As an industry, we are still learning 1 and 2
Security is slowly shifting from an administrative IT function to an operational function. In IT, the business value comes from the products and people are a tax required to administer the products. In security operations, the business value comes from the people, products are just tools in their toolbag. [c]
Keep walking this dog and you realize basic IT activities for core infrastructure are critical for security, to the point the CIO will report to the CISO -- unless the CIO steps up. [b]
So - in short - your frustrations are accurate, but the winds are shifting. Companies will incresingly value top people for their internal staff/blue teams. It's going to take a few more years, but I believe it is inevitable.
[a] - https://www.linkedin.com/pulse/my-four-cybersecurity-princip... [b] - https://www.linkedin.com/pulse/cio-report-ciso-j-j-guy [c] - https://www.linkedin.com/pulse/cio-report-ciso-why-j-j-guy
https://akamaijobs.referrals.selectminds.com/jobs/senior-lea...
https://akamaijobs.referrals.selectminds.com/jobs/security-a...
https://akamaijobs.referrals.selectminds.com/jobs/manager-in...
The other big thing to note is that a lot of companies have security teams solely to meet audit requirements. If you find yourself on a team like that, you'll be spending a lot of time just gathering evidence for audits, remediating findings and writing policy. I really loved security intellectually, but in practice, the blue-team side of things wasn't my cup of tea.
We're located in Boulder but for the right candidate we'd consider remote, although that might involve relatively frequent travel.
cGhpbGlwLmRldWNobGVyQGp1bXBjbG91ZC5jb20= for contact
However, unlike Certified Ethical Hacker, CISSP, and other "mile wide, but inch deep" certs, the OSCP is a heavily hands-on certification that tests actual ability. No knowledgeable employer would discriminate against you for earning it.
And CISSP or CISSM are valuable if you're applying for a management job. For government defense-sector jobs, they are often required.
https://www.schneier.com/blog/archives/2012/07/how_to_become...
2) The Reddit NetSec FAQ has a good list of resources for beginners (and those starting to specialize):
https://www.reddit.com/r/netsec/wiki/start
3) Finally, each of these popular "Getting Started in Security" guides has a slightly different, but useful, opinion on the specifics of the path to take:
https://medium.freecodecamp.org/so-you-want-to-work-in-secur...
https://danielmiessler.com/blog/build-successful-infosec-car...
https://www.trustwave.com/Resources/SpiderLabs-Blog/Getting-...
https://tisiphone.net/2015/10/12/starting-an-infosec-career-...
They're based in Amsterdam, but she said that a lot of their pentesters and engineers are remote (all over the world).
Might be worth reaching out!
What's surprising (at first glance) is that the security talent need is very strong in UI/UX/CX.
For example, security is needed to gradually escalate a user's own identity verification -- think of things like two-factor auth and multi-factor auth, that can phase in (or ramp up) when a user's actions enter a gray area of risk.
Some examples: when a user signs in from a new location, or a user does an especially large money transfer, or a user resumes an account that's been dormant for years, etc.
The UI/UX/CX is especially necessary to 1) explain to the user that there's a security issue, 2) how the user can fix it, and 3) how to improve backend systems to handle users who ask for help.
Which technologies specifically?
I think that's part of the issue, security minded folks are often very analytical and come from CS backgrounds and the demand is for people who understand how design interacts with technology to, in this case, create secure methods of actually using a technology.
So, to answer your question, none. It's about the mindset of the designer.
For security being a human problem, I have yet to meet infosec types with strong backgrounds in human factors or product design. Nearly everyone came to this industry from netsec/IT/SOC work, or low-level programming, and neither group has a decent understanding of the usability issues that plague the security posture of common users. What works for a CLI junkie with deep systems knowledge absolutely fails people who barely know how to navigate their Android phone.
If anyone's interested in attempting to solve some of these design pattern issues, please reply here or DM me on Twitter. I'd love to actually get a group of people together trying to come up with standard, secure UX paradigms that can be referenced by others.
I used to love doing pen-testing when I was a teenager, and paid for my first car out of bug-bounties.
Unfortunately, I got distracted by girls and booze at university and didn't keep it up, now I work in sigh enterprise C#/WPF land.
(Similar story:) )
There are so many sources of information and learning grounds available now - bug bounties, certifications, war games, online tutorials, blogs, conferences etc.
I would suggest choosing a particular area of interest to begin with and deep-diving on that subject. Look for mentors or perhaps someone to knowledge share / skill exchange with.
You could do pretty well with a base in C#. Through pentest engagements, I've come across quite a few C# apps in my time and even with my limited knowledge of the language, found some interesting vulnerabilities ;)
Edit: Added tptacek link
I believe what helped was a handful of personal projects related to security: reverse engineering firmware, finding bugs in web apps. Also I emphasised the parts of my software development work that had some overlap, such as debugging Windows kernel drivers, and doing security reviews of network services we were writing and deploying.
Now I'm doing full-time vulnerability research and writing software to help do that. Much more enjoyable and pays better too.
Everyone should be very, very scared about infrastructure/medical security and the effective lack of anyone doing anything about it.
I'm sure web/network pentesting is doing well though.
Excellent talk from last year's HOPE about the vulnerability of medical devices - he even connects to some live
And is it largely on site work, or is it more common as a remote consultant?
Junior: $120k base. $10-15k annual bonus.
Mid: $150k base. $20-30k annual bonus.
Senior: $180k base. $30k annual bonus.
Slightly skewed towards consulting; notch it up a bit to account for stock grants in addition to the bonus if you're thinking of something like Google, Facebook or Amazon. Sometimes the consulting firm pays separate bonuses for research time and bench projects that result in something useful or beneficial for the firm's brand.
That's based on my own experience and talking with probably well over a hundred people in the industry about their salary by now.
You can do remote, I've been remote almost my entire career thus far. Remote is more likely in consulting than it is at one of the reputable internal security teams, but it's not uncommon at smaller tech companies.
Security is usually worse than regular engineering, because it tend to be a succession of short quick gigs.