Someone inside a company sets up an Azure/AWS instance, to do sandboxing, and doesn't secure it.
Many of these giant data breaches, are because some Marketing person, set up an AWS instance, dumped their entire user DB into it, and did a bunch of data mining.
I think that most cloud providers are now defaulting to locked-down, but the issue seems to be, that folks are still going outside their org, to do this.
I suspect that having some kind of secure internal cloud setup would be helpful.
However, and this is a biggie: It needs to be easy to use. So many times, security has so many roadblocks, that folks work around it, simply to be productive.
In my opinion, security needs to be the easiest path. If it is not, then that is the fault of the Security folks; not the end user. I worked for a company that had such terrible security policy, that it basically completely stopped all productivity. You could tell who was violating policy, because they accomplished their goals.
Having a policy is worthless, if it is too difficult to follow.
Hit the nail on the head. As a security person, the marketing and data engineering teams at my company are what keeps me up at night.
They inherently desire to work with the company’s Crown Jewels of data. They want unfettered access to, and want to give other people access to, an entire data warehouse of some of our company’s most sensitive customer information. And when it comes to securing it properly, they often do not have the same engineering capabilities as software teams.
As a security person trying to work with marketing and data engineering teams, I've often found them very resistant to learning how to secure things. They generally want to use the tools they know, in the way they know, to do the tasks they understand, on a timeline they find convenient.
Anything that tries to get them to understand the risks they are taking or the sensitivity of the data, much less de-risk their workflows, is treated as an obstacle to be routed around. Often, the best I can hope for is a token effort at negotiation where their goal will be to avoid any and all changes on their part. After which I will have to monitor them carefully, because from experience the odds of them backsliding within a week are uncomfortably high.
Nothing about this is conducive to producing a healthy environment. When people's idea of "easy" is they can download the company's most sensitive data to their laptop to load into Jupyter, any amount of security controls will come as an imposition.
Log in to your vpn, then log in to a website to download a token. Then use said token to log on to a virtual desktop. From here you can open a browser and log in to powerBI, which has access to data in the data warehouse.
Yes, such workflows are something to be routed around.
For delivering strict network access controls, a clear audit trail at multiple points, and (at a guess) the usage of very temporary credentials to actually log in, yes. Especially if the same infrastructure is used for other, less SaaS-centric data handling tasks or users are in places that like to mandate access to geo-local data (India, China, etc.).
Security measures in operational workflows are only a little bit about what the end user - you - sees. Generally they're really about delivering something less obviously visible to the user but very valuable to the business, investors, and regulators.
Given that many data engineers have a data science, data analytics, BI, or software engineering background, I'm curious if you've noticed any trends in their approach to data security?
Yes. Generally it can be summarized as "What data security?".
Snark aside, there's usually a reflexive assumption that more data is always better and that anything that gets in the way of more data is bad. Anything that limits how data is analyzed is bad. Anything that limits or restricts their choice of tooling or where they use it is rejected.
Data scientists and engineers are people who are, often, working with a company's crown jewels. They are trusted with data representing the private lives of hundreds of millions of people assembled in a data warehouse. I want them to have a care. To treat this with due gravitas. All too often, all they seem to see is a neat data set to feed into R on their Macbook.
They inherently desire to work with the company’s Crown Jewels of data. They want unfettered access to, and want to give other people access to, an entire data warehouse of some of our company’s most sensitive customer information.
In my organization, the problem is the security people, not the marketing people. They're simply not responsive.
Someone on a non-IT team will send a message to someone in IT Security asking a question, checking to see if a procedure is correct, or if it's OK to so something, and the IT person simply won't get back to them in an acceptable timeframe.
I'm not talking about minutes. I'm talking days. I've seen my coworkers' IT Security tickets go unanswered for more than a week.
Yes, securing your big fancy data warehouse is very important. But guess what — hackers don't knock on the front door anymore. They're going through the small cracks that you allow to form when you don't realize that your job is securing the entire organization, not just your silo.
This is why the rest of the company is going around security to get things done. Because if the money doesn't keep flowing, everyone loses their jobs.
_Every single person_ in the security industry that I know is on the verge of burnout because we’re all running around trying to answer questions from other teams as fast as possible, but there just simply aren’t enough security people to go around, and I don’t think there ever will be. My security team coworkers each have a backlog of 50-100 unread slack DMs from developer teams looking for guidance at any given time, and it’s been that way for years. My team has been attempting to hire nonstop, but the pace of hiring can’t keep up with the demand.
Honestly, 1 week sounds totally reasonable to me. If you’re at the point where you need an answer immediately or it’s going to delay your timelines, then you didn’t plan your timelines very well, or you waited too long to engage your security team. You have to keep in mind that while you might be laser-focused on your app and think it’s the highest priority, your security team is likely dealing with hundreds of apps, each of which all claim to be the highest priority. Triaging has to happen, and it doesn’t always go in your favor. It really sucks for everyone involved, but I don’t see a good fix for it.
The sweet spot is empowering teams to make most security decisions on their own so the capacity of security people can be spent more wisely and development teams don’t have to wait for an answer except for in very rare cases, but the pessimist in me thinks we’re already too far behind on this and technology (and the opportunity for new security dangers to arise) moves too fast for us to ever catch up.
I think if you are acting in an advisory role, it's ok to have a backlog and take time to respond. If you are an approver/gatekeeper blocking ship of something, then it's not acceptable to just say "file a ticket, we'll get back to you as workload allows". Maybe have two tiers of tickets: Questions and approvals, giving approvals priority. At my company, the approvers are often the busiest people in the company (busy with other, non-approval related things too) and that never works well. You end up with frustrated clients looking to work around approvals.
Centralized data warehouse. Convenient tools for querying, running arbitrary jobs against, and building reports from that warehouse. Table and column level ACLs. Strong norms and policies against copying/transferring out of the warehouse for any reason except transient UI display. Sufficient capabilities within the warehouse that it's not necessary.
IME many security people are already on call. What you’re describing is one of the roles of Security Operations Centers, unless I’m misunderstanding what you’re suggesting (which I think might be the case!)
You can’t rely on that as a fix though, because it’s inherently reactive, when what you really want is proactive protections. By the time you get paged about a breach, it’s already too late.
I see! I think it’s a good idea, and I personally think that would be a good and overall positive role!
However in my experience in a big org, #1 happens frequently enough where it basically would be needed at all times, and would need a security person (or entire team) dedicated solely to that purpose. And sadly in my experience, companies are not willing to spend the money, or able to hire enough security people, to have that level of a dedicated security concierge for every team that needs it.
Maybe real security people training the most security-aware person on a given marketing/dev team, and giving them some level of authority? If orgs won't/can't hire enough infosec folks, maybe some of the basic knowledge needs to be spread to other roles?
I may be grasping at straws here. It just feels ridiculous that my national security is being risked by these obviously super-dumb moves made by trillion dollar corporations.
You're describing what's popularly known as a "security champion" program. The problem is you're giving a little bit of training and authority to someone who is primarily accountable for marketing/dev/whatever. At best, this sets up a conflict of interest that the person will occasionally navigate successfully. At worst, they now know enough to be even more dangerous.
The problem isn't just knowledge. The problem is getting people to use that knowledge to push back on bad ideas.
Thanks. I'm filing that phrase away for future reference. Again, I am just stabbing in the dark from the outside here:
From my external POV, it feels like for all its faults, Google/Alphabet took the time to create BeyondCorp, and does not have the same record of infosec errors that Microsoft seems to regularly display in recent times.
Is that correct? If so, in your opinion, what is the difference? They both print money...
Is this just a difference in "corporate culture?"
Disclaimer: I grew up in Kirkland/Redmond, have a bias that is favorable towards MS, and would love to understand what the heck is happening.
Google/Alphabet is willing to mandate - and then enforce - sweeping changes. When they shifted to U2F and forced everyone to use it, phishing all but vanished as an ongoing problem. I don't know if Microsoft is capable of that, technologically or culturally.
The NIST Cybersecurity Framework for small businesses is a great starting point for developing and nurturing a healthy cybersecurity program in a startup.
At my company, the big thing that I think would help is if people would stop treating data engineers as if they are a cheap way to get both software engineering + data analytics in one package. They’re not. Data engineers are brilliant at data things like writing complex pipelines and wicked queries, but they just aren’t as good at writing secure code. Meanwhile, software engineers are the opposite.
Data engineering teams need at least part of their team to be designated software or systems engineers that are experts in stuff like how to create a robust cloud environment. This is not only beneficial for security, but also for cost optimization, performance, operations, etc! It drives me crazy when I see a data engineer or marketing team told they have to fend for themselves when trying to figure out how to build a cloud environment.
In theory, there are documents out there a startup can read, understand, and follow to get reasonable outcomes. Theory is a wonderful place, I'm told. I'd like to visit someday.
In practice, the answer is to hire a consultancy. There are fractional CISO services out there. It's very likely that a startup without significant security experience in-house does not have the expertise to make good use of any guidance they can find. Every scenario is too specific, every personality dynamic too unique, and every new technology question too novel for there to be easy pre-fab answers that a non-security-practioner can find, understand, and apply in a correct and consistent manner.
> security needs to be the easiest path. If it is not, then that is the fault of the Security folks; not the end user.
There's truth to what you say, but you're blaming the wrong crowd. Security people are rarely (if ever) the same people that are creating the tools and the security features of the tools you're using. In most cases, I'm powerless as a security engineer to "make security easy to use", the only thing I could do in that regard would be to loosen our security requirements and make our systems less secure, which isn't what you want either.
IMO the problem is more that when developing products, security (and ease of security) is still not seen as that important of a feature (if its even seen as a feature at all and not an annoying cost that the product managers have to deal with). In our application security group, we actually do have requirements that any new product being built must have certain security features that make it easier to secure things, but those requirements are often some of the very first things that the product development teams try to justify delaying or ignoring.
Seems you are actually working with developers. At my company, the security people just say "no" but don't really work with people who have legitimate needs. So often you end up doing stuff on your personal equipment just to get something done. They also block sites like "nature.com" but don't block downloads from shady download sites.
It's quite possible to develop products that afford security. I'm pretty sure that I know why it doesn't happen, but I won't get into it.
In the app I just released, we take security very seriously. I have spent days on just the login screen, tuning it, so that it lubricates the sign on experience.
In fact, that's what I'm doing, right now. Some of our users have been getting confused with Sign In With Apple, so I'm looking at ways to make it even smoother.
At some point, "not taking security seriously" is simply negligence. Other fields already have ways of punishing people for negligence (up to and including suspension of licensure and/or prosecution). Why are software developers immune to consequences for not realizing they need to use parameter binding in their SQL statements?
To engineers, especially ones that use CLIs a lot, "UI" is simply "silly chrome for lusers."
However, the other 90% of users think that it is very important.
I have been looking at the signups for a while, and wondering why the SiA signups have been going unused (or the person tries again, with a non-SiA signup).
It was because of a "UX thing."
It's really, really important to take the "UX thing" seriously. It can make or break products. The OXO line of kitchen gadgets got huge, because the designer's wife was disabled, and he designed tools to make her life easier, which also made everyone else's life easier.
SiA is quite secure, but on my end, it could be quite insecure. It's basically an SSO-type thing.
The workflow is a bit different from the standard login ID/password entry. You use a "Sign In With Apple" button that the OS provides, and that has its own on-device (and cloud) credential generation.
I was not optimizing for the button. There's no need for a user ID, if you are using SiA, so I should not have presented that field to users. Also, some credentials are only available at generation time, and have to be maintained by the app (securely, in the keychain).
That behavior can get reflected in the UI, and may be confusing to folks.
SiA is the only SSO solution we use. I won't use anyone else's code for that stuff, and we keep all user data inside the app. We also don't collect very much.
"Start culling those who are doing the job poorly to start making space for others who may be able to do it properly"
How about starting to cull top level managers who constantly put pressure on people, don't hire competent security people but reward quick results that create future problems?
I dunno, if a commercial driver violates speed limits and hits someone, do we want to accept excuses that "It is top level managers' fault for giving me unreasonable timelines which require me to speed?"
Sure, the top managers is at fault, but individuals are also responsible for their actions.
If that commercial driver was slowly, but methodologically overworked, manipulated, fatigued and pressured into doing this with every incentive promoting speeding, then yes. Why did the driver feel compelled to speed in the first place?
Why would there be an environment or incentives where this could be a valid strategy?
This flows from the top down. The consequences to companies that leak private data are so minor why would someone lose their job for risking a leak? At worst it's a fine that amounts to a slap on the wrist.
Things that limit civil liability like mandatory arbitration clauses have made this worse.
Yes, consequences for negligence and maybe licensure are the only way we'll solve this problem. It's easier to write software without giving a fuck, and if it remains profitable and without consequence, it will continue happening. If you can't write internet-connected software without making basic security errors, you shouldn't be writing software, at least not without the guidance of someone senior (actually senior, not two years post-bootcamp). I can't believe this is controversial.
Lmao I love how suggesting that developers make take responsibility for their work is met with such hostility here. Nice job removing my comments, you jokes of "developers".
Once they're convinced it's the fastest and easiest way to have a wordpress instance they can publish to as they please, they most certainly are. Or, as in the example, they get the idea that having a database they can analyze will unlock key insights that will drive market share.
It doesn't matter if any of this is true. What matters is they believe it and it leaves them feeling empowered enough to invest.
It's not that difficult to do, it's literally day one of a "learning SQL and databases" course. You don't need that much tech savvy to follow a tutorial and start queries in what is a basically a big fancy excel workbook
And the first Google result will be the marketing blog of a SaaS talking about the business value brought by that SaaS, not a how to tutorial on spinning up an AWS EC2 and installing stuff inside.
marketing orgs often have at least engineering-adjacent people in them. And often they're just disconnected enough from the rest of the engineering org to make mistakes like this
10 years ago, the best tech skills on the marketing team were held by the person who knew Excel really well, including VBA calls to remote data sources. Maybe they were coding from copy/paste examples, but they were coding.
Today, give that person an AWS account and they can absolutely build cloud-based data solutions by clicking around and following SO posts. Add ChatGPT to guide them and the sky is the limit…on how much data they can expose.
The easiest path is always dangerous, because it's easier to avoid doing the right thing. It's easier to make cars without seatbelts. It's easier to avoid doing quality control for medication. It's easier to put lead in the paint. Somehow, computing hasn't realized that it is a field that maybe actually requires a little specialized knowledge. Would you let any rando fly an airplane? No, of course not. Why are we letting unqualified people write software?
> No, of course not. Why are we letting unqualified people write software?
Because in 99% of cases the code will never be able to cause harm to a human being and there is zero risk for loss of life.
The comparison you are making is kind of ridiculous. To work on the software that works on an airplane then you’ll be vetted appropriately but to work on random CRUD app you don’t really all that much.
> In my opinion, security needs to be the easiest path.
Secure data handling can't ever be the easiest path. The easiest path is to have all data available all the time to everyone with zero access controls. Adding any kind of security to that is going to reduce the ease, even by a tiny amount.
Security needs to be pragmatic, people have a job to do and a business to run. Security teams should never forget they are there to enable the business.
But at the same time, the company needs to have a culture that recognizes data security is important. If that is not present, there's nothing the security team can do.
Making doing things right has to be easy. You also need excellent monitoring, because it's inevitable someone will do something else no matter how easy.
There are plenty of people and teams who just want a button to push to run their build. That's not so hard. Give them a CI/CD system and they'll use it.
The problem becomes the people who want to use weird, wildly divergent build processes made of fifteen shell scripts strung together and downloading arbitrary content from random remote servers because they enjoyed engineering it. They'll insist on having a blank slate of a cloud tenancy because no build system can meet their needs. The CI/CD team does not take this case seriously and will never meaningfully support it. Security is in no way staffed to build out a major extension of the CI/CD service.
Perhaps it's the data team, who has decided they would like to datamine large quantities of private information at their leisure, in contravention of privacy policies and contractual language. So they'll jump through hoops and contortions and share passwords every which way in order to do the thing they want. They will deliberately set out to disable monitoring systems because they resent the implications. At no point will they pause to consider if any of this is a good idea.
It's not just about making it easy to be secure. It's also about being able to find and stop people being insecure. One of the important things a security policy - and security organization - does is set boundaries for what activity is and isn't permitted. Crossing those boundaries needs to be watched closely... and yes, punished.
> So many times, security has so many roadblocks, that folks work around it, simply to be productive.
This has been my experience. We had someone set a secure instance following all the policies and such. Then they moved to another org in the company and I started getting email violations going to the VP every few weeks because they didn't do some sort of attestation. The problem was only the user could do it and the automation had no guidance on how resolve the issue or stop the alerts. This went on for months before it was resolved.
Why didn’t the VP escalate it to the CTO/CEO (or whoever could start firing folks and their managers if it wasn’t fixed asap) after the first few emails?
Depends on your definition of “easiest.” It will become the easiest path to conduct business activities by throwing roadblocks into the insecure path. It will not be the “easiest” to use.
It’s the equivalent of lowering all the speed limits on every road to 10mph “out of an abundance of caution” instead of doing the hard work of determining the appropriate limits.
I work at a place that uses cyberArk for privileged AD accounts. I have to copy the password from the web UI to login to the system I use every day. If it times out, I have to refresh, respond to 2FA and copy it again.
I see coworkers storing their entire password (1 week expiration) in notepad in the meantime.
I was going to store the password in a portable Keepass, but I got blocked from accessing a software download website and was scorned by the proxy block page.
Frankly, I think the cyberArk method is effing foolish and having regular 2fa integrated into a product's login makes a lot more sense.
> are because some Marketing person, set up an AWS instance, dumped their entire user DB into it, and did a bunch of data mining
What the actual **. That's a very hefty GDPR violation and you should be fired for doing that.
> simply to be productive
If you are using private and sensitive data, that should be pretty much out of the question. You develop with a dummy database only, which doesn't matter if leaked. And after having finished testing, move to the actual data.
Where is the report that is the basis for this article?
The article basically says "these dudes told us they found some passwords for databases on an open machine". Ok, well a) that may not be true and b) they may not be passwords with high value. Just because something is a "password" doesn't mean it is useful for anything.
There seems to be nothing on the web about this incident besides more articles repeating the TC mother article.
Doesn't surprise me. I know a managed service provider who keeps all his clients' AD domain passwords on a text file on his desktop. How do I know this? I saw it on a screen share.
Security trainings just that, trainings. Some teams and even EMs don't pay enough attention to actually following them. Also, in many orgs within Microsoft there's a lot of legacy setup that was there before the trainings or before the org became a part of Microsoft and sometimes there is no capacity within the teams to address/fix this legacy setup. And if they're unlucky enough, someone will exploit it.
In some of the orgs and products there are zero career incentives for addressing legacy setups and there are big incentives for pushing out new features and initiatives. I've never heard of anyone being promoted for driving an initiative to fix obscure technical debt like this. It's a systemic issue that won't be resolved with security trainings.
Because corporate security is about "compliance" and "training", not solutions.
Awareness is one weapon, but really security is so technically complex to do well is that security needs to offer good solutions.
Think of it like a GPT prompt: "give me a test harness for user profiles" "give me a secure login process" "give me a SSO service"
Instead security groups want to "review"/"approve" which is just shitty compliance overhead. Because of course they don't want to be the ones to blame for bad security code. They want their compliance review checkbox, and everything else was the "evil rogue programmer/hacker" to blame.
And alas, the security people I've seen in large corporations I've worked at have been almost morons. Internal support portals for enterprise passwords? Dumb password rotation rules, 6-8 character limits, and chrome complaining about obsolete ssl suite usages. Degrees from specious Florida universities that mostly seem to be about tuition collection and beach access than actual academics. Asking them about major breaches and the technical basis of them and getting blank stares.
No idea what the vaunted Amazon or Microsoft do, hopefully it is better. Amazon abuses its employees, so that opens them to a rich array of social attacks and leaking, in addition to the high probability that Amazon farms its customers for business strategy. Microsoft has always been about monopolistic sociopathy trumping technical concern.
Cloud providers are a high customer support business and it is resoundingly obvious that Amazon and Microsoft view those in as high regard as most SV organizations and really all corps in general: low paid and overworked, if any.
Corporate management will only invest in things they see are worth the reduction in managerial bonus payout, kinda shareholder value, kinda risk reduction (at least within the period of time their stock grants are active). There's really no good aligned incentive, just like environmentalism because it is an unquantifiable risk to the great religion of economics and finance, and therefore doesn't exist.
>"give me a test harness for user profiles" "give me a secure login process" "give me a SSO service"
> Internal support portals for enterprise passwords? Dumb password rotation rules, 6-8 character limits, and chrome complaining about obsolete ssl suite usages.
I'm curious as to why these would require some outside security group to deal with? These all seem like issues that should be solved either by someone in the devops category.
Update your dependencies, disable unused protocols, have a QA guy find your improper memory glitches, and now 99% of the security establishment is irrelevant to you. These are operational issues. Most security issues are just operational issues.
Microsoft employee here and I actually really enjoy the standards of business training.
Generally I find that I mirror the effort I put into training to the effort the creators put in. If a training is just 20 slides of text to speech, I will put that on 2x on a background thread.
If the training is a well-produced video series I'll watch the full thing at normal speed.
People will always choose convenience over security.
I'd figure out what the least-technical person (with data access) in the company needs to do their job, and find the friction points that prompt this person to find the path of least resistance.
2FA in general makes a bad solution worse all for the sake of security; it's not long for this world.
>2FA in general makes a bad solution worse all for the sake of security; it's not long for this world.
Can you expand on this?
With reasonable setups (trusted locations and trusted devices) the friction is absolutely minimal. And it isn't even a question, the security benefits are astronomical.
I am not understanding how you can say 2FA is "not long for this world".
1. Traditional way:
- type email/username
- type password
- click submit
2. 2FA way
- type email
- type password
- click submit
- switch to secondary email/text app
- wait for email/text to arrive
- copy text string (not consistent, depends on input method)
- switch back to main app
- paste or manually type text string
- click submit
3. Hybrid (passkey?) setups are a great step in the right direction. Even more convenient than passwords, and more secure, without app switching, which is the huge friction point.
My average 2FA experience when setting it up for the companies I consult for is.
Enter credentials -> receive push notification and press "yes" -> login.
They wrote #2 to be purposefully long and convoluted. "Copy/paste code" is somehow 5 steps, with a waiting period? We really needed to detail out "switch app" as 2 steps? Come on.
As another example:
If you were to give directions to someone on how to get to your house, do you say: "Turn right at XYZ street, follow that up to ABC street and take a left, last house on the right"
Or do you say
"When you are 50ft from XYZ street, press on the brake pedal. When you get to the corner, turn the steering wheel to the right, hand over hand, then get the car straight again, press your accelerator, approach the speed limit, check mirrors every 20 seconds [...]".
Both are true. One is unnecessarily detailed to make it seem more complicated than it is.
I have certainly worked with aging populations, people who have barely any experience with computers, etc. While consulting, I have probably walked a few thousand people through MFA setup and use.
I have not tried to set up MFA for someone with memory deficits, so I can't speak to that.
All of that is completely beside the point, though. I'm not sure why it matters. There is 0 chance that MFA is "not long for this world".
That depends basically entirely on what the second factor is and how often you are requiring it.
Imagine futuretopia with me for a moment; when you are hired at a company they send a very secure cryptographic keygen to your subdermal ID implant. Maybe with 3 different fields for "employee" "division" "role"
When you enter the building, implant comms automatically using "employee" with the mantrap pads acting as a second factor as you type in your yearly revolving 9 digit employee passcode
Same with the workstation when you log in using "division", and maybe when you specifically access certain files "role". They all last a user session length, and can all use the employee 9 digit as primary login
This scenario gives you effortless 2 factor, 3 different times, and the employee only has to put in their simple 9 digit code thrice daily, maybe 6 times account for lunch break.
Does this scenario seem like two factor that's on the way out and causing more problems and inconvenience than it's worth?
Two factor sms where you have to type the code in yourself and sms is insecure? Sure that's dog shit. But we can make a better future instead of disregarding a pretty solid security concept
> Imagine futuretopia with me for a moment; when you are hired at a company they send a very secure cryptographic keygen to your subdermal ID implant. Maybe with 3 different fields for "employee" "division" "role"
This is immediately the wrong design and is confusing authentication with authorisation.
Your "subdermal implant" needs only one feature, (two if we wanted greater privacy than exists for employees today, but let's not get ahead of ourselves)
1. "I am still me". The implant can produce a copy of its public key, and will cheerfully sign simple freshness challenges allowing the employer to confirm that this is the same implant that the person hired had.
That's all you need, that's the whole thing. The question of whether you're in Org Unit A9 or ZQ, whether you're a Deputy Senior Assistant or a Senior Deputy Assistant, whether you're part of Divison F or not, these aren't authentication they are authorisation questions and there is no need for them to belong to you, they can live near the decision since they can be changed by other people - you can be demoted or promoted, moved, reshuffled, fired - that's not a decision for you it's a decision for somebody else.
Security sucks to the average joe. I tried to help my Mom set up 2FA and...it didn't work out well.
Most average people are just confused by it, but it's so important for security the focus shouldn't be getting rid of it, but figuring out how to make it buttery smooth to use.
Faced with leaking internal data or having a broken system, you pretty much always choose the latter. You simply don't leave your front door open. Roll the secrets, break the system, and then fix the mess.
The system was already broken from the moment credentials were leaked (or if you're a purist, from the moment they were hard coded into a file). The impact just wasn't realized or felt yet.
If there's a risk of exposing business secrets or user data, no, it's 100% black and white. It's weighing some downtime and/or annoyance against _unbounded risk_. It's unethical at best to choose uptime over revealing user data or the remote access to internal systems which you don't understand the complexity of.
I struggle to see when a business responsible for life support services in an industry like medical would choose to end lives over delaying the addressing of a data breach but maybe I’m not seeing the bigger picture?
1. Microsoft isn't in the business of life support systems. Turning off a system with exposed credentials isn't going to shut off all of Azure. Even if it did, are you really claiming that Azure downtime is life-and-death?
2. In what hypothetical universe does a life support system connected to the internet contain a trove of customer PII? And where disconnecting this hypothetical system from the internet _cause the patient it's supporting to die_?
I thought the discussion was extending beyond Microsoft and applying to any software. But if you are asking if it’s possible for Microsoft Azure to be the hosting provider for very important systems ie government, medical, then yes, these could impact a high degree of quality of life for people, even now or in the future.
> if it’s possible for Microsoft Azure to be the hosting provider for very important systems ie government, medical, then yes, these could impact a high degree of quality of life for people, even now or in the future.
If you design a system that could cause significant personal harm or a meaningful degradation of quality of life for someone due to cloud provider downtime, you're just a bad engineer. There's no such thing as a data center that's failure-proof. If someone's well-being depends on a system, it's simply negligent to be intolerant of failure conditions.
I agree, there are many terrible systems around the world with terrible implementations that at best cause inconvenience to people and at worst lead to a loss of life. My point is if you are faced with a data loss you make a call that assesses the impact of downtime and don’t follow a blanket rule.
Not familiar with Microsoft’s offering, but $WORK uses a similar product and it is the worst. All sorts of technical and usability problems. Way more friction than doing things the easy way.
I grit my teeth every time I have to interact with it. Not surprised some people use any other solution at hand.
I find it impossible to believe that Azure as a whole organisation takes security seriously. There might be individuals that do, but definitely nobody with decision making power. Half of the above described exploits are trivial and should have never passed any sort of competent review process.
> The panel said the intrusion, discovered in June by the State Department and dating to May “was preventable and should never have occurred,” blaming its success on “a cascade of avoidable errors.” What’s more, the board said, Microsoft still doesn’t know how the hackers got in.
...
> It said Microsoft’s CEO and board should institute “rapid cultural change” including publicly sharing “a plan with specific timelines to make fundamental, security-focused reforms across the company and its full suite of products.”
Someone inside a company sets up an Azure/AWS instance, to do sandboxing, and doesn't secure it.
Many of these giant data breaches, are because some Marketing person, set up an AWS instance, dumped their entire user DB into it, and did a bunch of data mining.
I think that most cloud providers are now defaulting to locked-down, but the issue seems to be, that folks are still going outside their org, to do this.
I suspect that having some kind of secure internal cloud setup would be helpful.
However, and this is a biggie: It needs to be easy to use. So many times, security has so many roadblocks, that folks work around it, simply to be productive.
In my opinion, security needs to be the easiest path. If it is not, then that is the fault of the Security folks; not the end user. I worked for a company that had such terrible security policy, that it basically completely stopped all productivity. You could tell who was violating policy, because they accomplished their goals.
Having a policy is worthless, if it is too difficult to follow.