We once had to fight for stackoverflow access. Security responds: you devs should only require the manual provided by the vendor(in this case: Oracle javadocs)?
Dash (or its Windows equivalent, name escapes me) can be used to view and search these dumps (as well as dumps from GitHub, language docs, etc) offline: https://kapeli.com/dash
The problem with security people is that they think security is the most important thing.
A good security admin will work within the bounds of compliance to make the business work. And any good blocks will be apparent to the user. Trust me, security doesn't enjoy pissing people off, we just accept that it happens sometimes.
He was on the phone with the CISO who was explaining it's impossible to give him access to SPLUNK because of the network segmentation.
While he's ON THE PHONE, he received an email from the IT group with credentials to access splunk.
And to be clear, I left specifically because of their security stance. I was once told they couldn't automate pulling data from production because of the same reason as mentioned above, the network segmentation wouldn't allow it.
So no, developers aren't just whining because they can't directly access PAN.
Security people always think their concerns should trump everything else. I would almost be willing to bet 70% of the mind-numbingly stupid decisions made across the industry had some security justification behind it.
If human beings took the same approach to safety that Security people do to security, they'd insist the wheels on your vehicle should only be able to turn straight and right. That the vehicle should _actively_ prevent you from turning your wheels left because left turns are more dangerous than right turns and they can show that you can _always_ get to your destination with just right turns.
One of my former employers has developers, network admins and security professionals working together to maintain a deployment pipeline using Github, terraform and AWS to let developers do as much as possible without having to request anything from security, ever. All the guardrails and checks are built in. Labs get to deploy just about anything, test and prod are identical, and prod has implicit restrictions on requiring encryption for data, prohibiting excessively powerful roles, and so on. But they've worked directly with development to get them everything they need ahead of time, in order to make IT and the business as effective as possible.
Security is necessary, and good security does what it can to stay out of the way.
For pulling data from prod - this is often discussed. Data in production should not be pulled in lower environments (dev and test), because of segmentation, but you can absolutely operate with Prod data within prod environment, like by using approved production datalake or data warehouse or something.
Believe for every security decision that you think is stupid - there are many incidents that happened, and every rule and ban has happened because of these incodents/breaches/data corruption, etc.
It is like workplace safety instructions, they were written because of workplace injury, same for traffic laws.
That's everything that's wrong with the security mindset.
And statistics of developers falling victim of phish attack, credentials stealing that leads to major breach - there are plenty. The most recent Uber hack or Okta hack - were all tied to developer clicking on stupid stuff, opening executables from Internet and getting his a$$ owned.
You just gotta accept the fact that developers are not security specialists, most of them cant even create a software without introducing plenty of bugs and vulnerabilities. They mostly google stuff and copypaste from stackoverflow, install shady barely working packages and copypaste directly into production whatever code snippet they found on the first page of Google results. Thats why they need extra control from security specialists
And now I'm going to quote myself from earlier to make it clear you're displaying exactly the silliness I was speaking to, with added emphasis.
"If human beings took the same approach to safety that Security people do to security, they'd insist the wheels on your vehicle should only be able to turn straight and right. That the vehicle should _actively_ prevent you from turning your wheels left because left turns are more dangerous than right turns and THEY CAN SHOW THAT YOU CAN ALWAYS GET TO YOUR DESTINATION WITH JUST RIGHT TURNS."
---
You see, you can still get to your destination with no left turns, it's just really damned inconvenient and has costs in terms of happiness and time.
It's a classic case of security people making decisions they themselves don't have to pay the cost of.
And don't get me wrong, you'll often hear security people _CLAIM_ they do, in fact, adhere to all of the security practices they insist on. And they may even do so.
But ...
THESE SECURITY PEOPLE ARE NOT DEVELOPERS.
There's no critical thinking in these decisions. A phone agent working in a very specific application all day doesn't need access to the PC the way a developer does.
---
> And statistics of developers falling victim of phish attack, credentials stealing that leads to major breach - there are plenty. The most recent Uber hack or Okta hack - were all tied to developer clicking on stupid stuff, opening executables from Internet and getting his a$$ owned.
uber hackers got through using slack, okta was a technician RDPing in.
Neither were developers, and unless you're prepared to claim slack wasn't sanctioned by the company, it's all just a long worded admission that removing local admin rights didn't actually help.
Then there's the question of, if someone steals a developers credentials, what do they have access to?
THAT is where the rubber hits the road. I've literally seen the following:
- Disallow developers from running powershell, but they can log directly into DB's with PII and PHI data ("they had a legitimate business need").
- Force developers making 6-figure salaries to "request access" for admin or the installation of software, said requests being granted by support teams of people making a little over minimum wage.
There's a reason why so many people call it security theatre.
> You just gotta accept the fact that developers are not security specialists, most of them cant even create a software without introducing plenty of bugs and vulnerabilities. They mostly google stuff and copypaste from stackoverflow, install shady barely working packages and copypaste directly into production whatever code snippet they found on the first page of Google results. Thats why they need extra control from security specialists
The reason your company is full of such developers is because you took away local admin rights and the ones with options left. You don't even have any left who could mentor the ones that need mentoring, they left too.
Put yourselves in the shoes of that developer who can access PHI at will, but cannot update their Visual Studio in the name of security because it requires local admin rights to do so.
One possible thought - they think very highly that you will do the proper thing, but they cannot and do not trust every single vendor out there. Have you heard of SolarWinds?
And honestly updating Visual Studio is something that can be arrange but would take probably 1 hour of IT time to solve and I'm sure they have other things they need to do.
Developers are not special to NEED admin access. they may WANT it because it's more convenient, but convenient is not secure. Maybe you're the most 1337 developer out there, or maybe you're a corporate spy.
Perhaps instead of lashing out and getting angry, approach this like a developer - what are they trying to achieve? Do they have technical debt like you? Is this a good enough solution for most use cases?
Inconveniencing you is not the main goal, so perhaps understand what their main goal is.
using your car analogy - car designers created steering wheel, blinkers, and mirrors to increase safety, but you insist that since you are power user - you want to be able to turn left/right by drifting using parking brake. This is obviously safety risk on public roads, and understandable how corporate fleet employer like Greyhound might not allow drifting when driving company bus with passengers.
You are free to drift on your personal equipment though, during non-work hours and without wearing company clothes.
Developers really dont need admin rights, Visual Studio and any other software is updated automatically these days using tools like SCCM. This is not an issue at all. If you need full control over OS - install free VirtualBox, or get a lab VM and do whatever you want inside that isolated VM, but not on the host machine. Because your machine is tied to AD, email, bunch of other corporate stuff - IT cannot risk giving admin rights, so that you can disable all necessary security protections.
Just because you are power user, doesn't mean your colleague in next cubicle is as smart and doesn't click on phish Linkedin emails.
PII is not an issue at all, because of security endpoint agents, network traffic inspection, data loss prevention, and network segmentation, and bunch of other security controls.
Just because you make over 6 figures doesnt make you any better than minimum wage IT support folks, they are following scripts and established procedures very well, most of them do their job well.
I agree that a lot of places have security theatre, because Security engineering is even rare skill than software engineering, it is much harder to find skilled seceng than SDE.
But things like SQL injection, shell command injection, url traversal, and zillion of other attacks - are made possible by software developers, and it becomes then SecEng's problem to protect company against whatever crap they coded and pushed to prod.
Most of the time, I genuinely wish it wasn't. There's so much I have access to, that I would never, ever need. And because I have that, I can't access things I actually need.
Just give me a iPad for all the corporate stuff and let me work on an open PC.
First you compare the risk of losing limbs to having admin rights, now it's drifting on public streets is like wanting to install python.
You can't find anything reasonable because there isn't any.
Consider the possibility that you may be wrong.
Decided the idea was not worth it to fight with infosec guys.
Turns out that a one-checkbox-tick fix was all it took to make that go away. The woman in charge of the web proxies panicked, thinking that this change had "broken something", reverted the change, and then refused to change it back.
Fun times.
The A stands for availability and if you don't make things available, you're failing at your own job.
Confidentiality,
Integrity,
Availability.
There are other IT protection goals, including authenticity, privacy, reliability, and (non)repudiation.
These fall under integrity, confidentiality, availability, and integrity respectively! The CIA triad is pretty comprehensive!
Authenticity and non-repudiation falls under integrity.
Privacy falls under confidentiality.
Reliability in context is another word for availability.
Also, the link to "request an exception" lead to a 404 and the IT team responsible for the blocking didn't respond to email.
Oddly enough, I can get on imgur
For example I wonder if javadocs shows you how to convert an InputStream to a string, as per this question: https://stackoverflow.com/questions/309424/how-do-i-read-con...
If you don’t have a starting point like that from prior experience or stackoverflow, you’re stuck clicking around the package lists, hoping to land on something useful
CC: Management
With such a strategy for learning everyone would end up in IT security.
Regards,
hyperman1