Do your threat models include your staff?
Of course, nobody has admin access.
Do your threat models include your staff accessing restricted information that they need to access?
How do you stop somebody from doing their job?
IME this is a great interview question to ask potential employers. The rabbit hole that you are required to go down will open eyes.
The answer is: you can't.
But how you mitigate damage (with data silos) and engage in disaster recovery after the fact puts you in excellent condition to weather any storm.
> IME this is a great interview question to ask potential employers.
That also sounds like an easy way to immediately exclude yourself and cut the interview short. It's sort of like interviewing someone for a security position, and them asking "by the way, what brand of locks and safes do you use, and what's your alarm company and specs?" It's not hard to see how it could be taken the wrong way, and giving information about internal security procedures (even generalities) to someone not contractually obligated to the company in some way doesn't seem a good idea to me.
We had a guy like that at my old job. He immediately made everyone suspicious. His first day, he constantly asked about security cameras, which doors were locked at night, how valuable everything was etc. He was frequently found in weird places with no explanation, seemed uninterested in anything about his actual job or even beginning to learn why he was there or what his tasks would be, and just generally gave off the vibe of 'was planning some oceans 11 shit' or something. He seemed oblivious to exactly how odd and suspicious he was being. He only lasted a few days, I'm honestly not sure why the boss kept him around that long. Nobody was impressed.
I guess my point is, if your genuine concern is security, definitely make sure you're not coming off like you're planning some grand movie heist.
He was probably one of the oddest people i've worked with, turns out nobody checked his out of province reference and when they finally did, nobody'd ever actually heard of him at his 'previous place of employment' so who knows.
Hilarious - I worked with someone in the past that was very similar. They lasted a few weeks. We ignored some yellow/red flags when hiring, so it's our own fault.
Yeah we were short staffed at the time. I don't think they were paying that much attention as long as someone seemed to check out at first glance. We want through a bunch of people that didn't last long around that time. He was probably the most memorable though.
Security folks always condescendingly lambaste companies not using best practices, but security is literally the worst. It's an infinitely deep hole of money, time, and CPU cycles.
If you create a startup with security best practices you'll never get anything done because you have to build everything in a way such that you don't trust anyone, including your own staff. So now your staff have ball and chains shackled to their ankles to prevent them from misbehaving (but also preventing them from having agility).
It's 100x cheaper and easier to do the cheapest 80% of security, and then hope that you don't get exploited by the other 20%.
Startups are fine I think: in a 4~10 people company every employee is the equivalent of VP and each getting admin access to company’s DB for instance is par for the course.
If you can’t trust your CTO you have other issues at hand.
You say black hole, us security people call it a "hard problem".
I mean lots of IT things are or end up being black holes.
I will say though, usually, attitudes like yours end up causing more problems than they solve (casual dismissal of security in general, more of a bother, doesn't stop everyone, waste of time, etc. etc.)
I like to think of security like this: My goal is to make it as hard and annoying as possible for bad guys to do bad things to the systems I'm responsible for. Yes, black hole, but my (infinite) glass is half-full.
The problem with security is that there is never "enough." It's a game of cat and mouse that will consume ever increasing amounts of time, money, and electricity until the end of time. Time, money, and electricity that could be spent on other things. Pretty soon I expect 50% of my electricity to be uselessly devoted to spectre mitigation and other security concerns instead of, you know, computing useful stuff.
Yes, I get we live in a world where bad people take advantage of others, making security necessary.
But if security people had their way, hobbyists wouldn't be allowed to hack together a side project without first hiring a $100k/year security specialist.
> My goal is to make it as hard and annoying as possible for bad guys to do bad things to the systems I'm responsible for.
By making it hard and annoying for the good guys to do their job as well. I know it's all necessary, but you can't deny that. Having to beg and plead with the IT security gatekeepers every time I want to [open a port for a webserver/install some package/etc] is more onerous than me having sudo privileges, especially when IT tickets take 2-3 days to resolve. And that's just one example. Anything security related is usually a pain. HTTPS is much more painful than HTTP, for example.
Security is a trade off. Everyone knows that the most secure computer is one that you never turn on; the job of your security team is to strike a balance that is better than that.
> the job of your security team is to strike a balance that is better than that.
There are two ways to strike a balance. A cooperative way, and a competitive way. A cooperative way is when all sides get together and hammer out an optimal solution, and then implement it in agreement. A competitive way is when everyone pushes to maximize their interest, and through the fighting, an equilibrium establishes itself[0].
I think GP is complaining about security teams that approach their job in a competitive manner, instead of a cooperative one.
--
[0] - You'll note that this is how competitive markets work; this both makes them a robust decision-making mechanism, and an incredibly wasteful one.
Firms in competitive markets don't fight, fighting would be if one firm's products somehow un-manufactured another firm's products. So, the defense industry, and nothing else. They hurt each other's bottom lines, but help society as a whole by collaborating to produce more of whatever it is they're selling.
> fighting would be if one firm's products somehow un-manufactured another firm's products
They absolutely do, and would do it much more if most ways of doing that weren't strictly illegal. A particularly notorious, legal way of unmanufacturing your competitor's product is when both yours and theirs rely on a common component - so you can buy out the entire supply of that component to prevent your competitor from releasing a similar product after you. Off the top of my head, Apple did that with these mini hard drives for iPods.
A more common example of fighting is advertising, which becomes a zero-sum game when the market for a product category saturates.
> Everyone knows that the most secure computer is one that you never turn on
An attacker might gain physical access to your turned-off computer and wreck all sorts of mayhem (install a hardware keylogger, rip the hard drive out and recover stuff from it, etc). The most secure computer is the one that doesn't exist.
An attacker with physical access could install an LTE-controlled power outlet and then remotely turn it on and use it to mine cryptocurrency whenever you aren't around, stealing your electricity. Ok, maybe that's a stretch...
Do your threat models include your staff accessing restricted information that they need to access? How do you stop somebody from doing their job?
That's precisely the hard question, but I think you can reframe that question: "How can you tell when somebody is accessing data that isn't necessary to do their job, in a given specific case?"
For example, could you correlate access logs to support tickets to make sure a support agent was only accessing sensitive data corresponding to the customer whose ticket they were working on? Could you do that in a mostly transparent way? What if the customer has to explicitly grant access before the agent can open the account for investigation? (None of these ideas are silver bullets, they're all situational possibilities.)
I don't think there are any easy answers, but I do think there's some granularity to how hard any given company finds it reasonable to try to guard against this issue at a behavioral level.
This may be a killer app for capability (security) model' approach. The "bored admin" of another comment in this thread has a 'superuser' ACL grant, and would leave auditable traces [if using] a provisionally granted security capability.
I worked on a HIPAA application years and years ago. I don't think ANYONE was above having their access logged. I'm sure banks have also solved this problem too of no-unauditable access.
Of course. But the question is if a smart, malicious, dedicated insider with a lot of privileges could find some way to access information while evading logging and covering their tracks in other ways.
Though I feel obligated to add that I think the above fact doesn’t mean an organization shouldn’t try at all to protect against insider threat. Most are opportunistic, not all of the qualities you mentioned.
How hard you try depends on your company’s situation. Some industries make it more necessary than others.
You can't stop someone taking it, but you can audit the hell out of it so when stuff gets misappropriated you can find out exactly who was responsible.
The problem with this is that first somebody has to notice.
In banking the reports will flow in quickly if somebody lost money.
In Roblox, when somebody created in-game currency out of thin air or accesses private information of other people, then chances are nobody notices and the audit logs are never manually investigated.
Doing automated audits then again brings up the question: how do you determine if something was the result of a genuine support action or fraudulent. You can try to find/train algorithms to detect that, but given that you can only train it against common fraudulent patterns, and do not know about unreported cases by the very definition, you cannot be sure such a system is operating well and/or cannot be easily gamed.
Banks have it easier in that regard, because the books have to match end of the day.
The law being the deterrent didn't really help here either. According to the article the "hacker" either bribed somebody for access, phished somebody for access or used some vulnerability to gain access. All of which isn't exactly legal, so the deterrent already did not work, tho it might make your own employees think twice about accepting bribes. But the hacker probably will not care about your audit system beyond the point of defeating it long enough to gain whatever they were out to gain.
Right because there's no fraud in the financial sector.
The last time my debit card got stolen the fraud people at my credit union suggested checking my account daily to catch it as soon as it happens again. They didn't really even expect to be able to prevent it. Or pretend like they would try.
It's apparently my responsibility to make sure they didn't just hand out some of my money to whoever walked by and asked for it. They never know exactly who was responsible because they were responsible. Of course the law doesn't see it that way.
Banks don’t take more responsibility for participating in fraud than credit unions. The law puts the burden on consumers to both detect fraud and ask politely to have their money returned.
At least with a credit union the customer service is a bit better because incentives are more aligned.
Every time a friend or relative asks my opinion on some tech that involves cameras or microphones I always point this out. Usually by asking How comfortable do you feel with a bored admin watching you? How well do you think the company is monitoring it?
On top of that, how much do your personal threat models overlap with your boss's or the executive staff? How much do they trust your judgement/expertise? How well do you demonstrate judgement/expertise? If you are the executive staff, fantastic - one less thing to worry about.
You are missing some techniques there. For example, to access any production user data where I work, I have to fill out a lease form and someone has to approve it. So you can technically have no one with admin access on their own without documentation and oversight.
Require an active ticket to access stuff, that needs approval from a second person. For very sensitive matters (say doing large transfers in a finance/bitcoin company), make it three or more people.
This is Mr. Eddie Vedder, from
Accounting. I just had a power surge here at
home that wiped out a file I was working on.
Listen, I'm in big trouble, do you know
anything about computers?
Right, well my BLT drive on my computer just
went AWOL, and I've got this big project due
tomorrow for Mr. Kawasaki, and if I don't get
it in, he's gonna ask me to commit Hari Kari...
Yeah, well, you know these Japanese management
techniques.
Could you, uh, read me the number on the
modem?
--Dade social engineers a security guy over the phone in Hackers
> This is Mr. Eddie Vedder, from Accounting. I just had a power surge here at home that wiped out a file I was working on. Listen, I'm in big trouble, do you know anything about computers?
> Right, well my BLT drive on my computer just went AWOL, and I've got this big project due tomorrow for Mr. Kawasaki, and if I don't get it in, he's gonna ask me to commit Hari Kari...
> Yeah, well, you know these Japanese management techniques. Could you, uh, read me the number on the modem?
I'll be using this example for years to come with clients who push back on why certain logging and alerting functionality has to be part of customer service related user stories as an acceptance criteria! There is always the insider threat!
Seriously. This fits directly one of my go to examples of a user story that needs security constraints:
"As customer service, I need to be able to help my customer regain access to their account easily so that they can continue to do business with us."
I'm teaching a group of developers about Risk Assessment and threat modeling on Wednesday. This is perfect timing to enhance the lesson slides with this story and have them think about "Fraud Against People Assets".
As customer service, I need to be able to help my customer regain access to their account easily so that they can continue to do business with us.
Security Threat: Customer service agents may use their trusted access for fraudulent, purposes.
Compensating Controls / Acceptance Criteria
1. Software should log all customer service actions and write to a file that is kept for 1 year for review
2. Users should be informed that their actions are logged in clear, bold language when accessing customer portal
3. Notify customers at already known contact when anything about their account is changed by customer service portal
I’d categorize this under social engineering, so... probably counts.
But the terminology issue seems like a surface detail. The attack vector (bribing an insider with front door access to customer data) is a pretty big and actively exploited class of organizational vulnerabilities, so it’s a security problem anyway.
It is a security problem but it’s not hacking. Default passwords are security problems but they’re also not hacking. Overhearing conversations in an airport or bar or whatever where sensitive information is disclosed is a security risk but also isn’t hacking.
Hacking almost always involves a decisive understanding of weaknesses general and specific to a system. Most of us know what default passwords are but don't have the initiative or ability to find an opportunity and actually exploit it. Similarly, just because I know what a bribe is doesn't mean I think it's trivial to bribe someone successfully and gain useful escalated privileges to a very large system.
Overhearing something accidentally isn't, but purposefully putting yourself in proximity so you have a chance for that is espionage and possibly social engineering (depending on whether you're just near or playing yourself off as part of a similar group).
In many ways, this is close to the original term of hacking, which is less about computers and more about circumvention of restrictions and security.
Hacking imho implies a workaround or circumvention that has a certain degree of cost-effectiveness and an indirect angle of attack (e.g. many types of remote exploits). For example, I don't know if I'd consider a brute force calculation of a password to be "hacking", if the cost and time of computing resources outweighed the potential gain. And while hacking a user's arm off might be more "cost-effective" (to put it coldly) than brute forcing their password, it essentially requires the resources and opportunity to have very direct physical access – in the same way that blowing off a bank vault door with explosives doesn't feel like "hacking".
But in any case, I don't think bribery as an effective attack vector for a service as big as Roblox is so self-evident that it lacks cleverness or insight. It's not just the work of finding someone with access privileges (could be as "easy" as searching LinkedIn for people listing Roblox as an employer), but also knowing what to bargain for (e.g. account credentials versus "give me the password of the richest Roblox player"), and having the confidence that the system would allow me essentially unfettered access (i.e. weak access-control policies and threat detection).
Logically, if bribery is such a straightforward and cost-effective attack, then people would be going hard all the time bribing insider employees at a bank. Yet if I had the money and time and willingness for illegal behavior, I'm not at all certain what unauthorized access I could get from any bank employee, nevermind how far I'd get undetected.
To put it another way, "legitimate" hacks usually reveal major substantive ways that a system can/should be hardened. I think it's pretty obvious how Roblox's access-control and auditing should be hardened after this kind of intrusion. How would a company realistically improve its security after learning a user's own account was compromised after the user was tortured into giving away their credentials?
Fair enough. I could get on board with your way of delineating it.
The way I see it is that modern day "hacking" and "espionage" form a venn diagram, and that particular distinction isn't important anymore when it comes to attacking and protecting businesses in digital space. Espionage based tactics for digital intrusion, including getting physical access to the digital assets, are usually fair game for pentesting and are often within the scope of the blue team.
How do you define "hacker"? This site changed its name from "Startup News" to "Hacker News" [0], but I don't think it signaled a complete shift in userbase and topics.
In any case, the article says the person "changed the password for and stole items from Roblox users". Would you say it's wrong for those users to describe their accounts as being "hacked"?
edit: moreover, no matter the method of intrusion, it shows how basic/non-existent the auditing and access-control is for a system that services 100 million active monthly users, which is most definitely the kind of security issue that traditional technical hacks reveal.
It must take some skill in developing relationships -- Who has access to the information? Who is willing to take a bribe? What amount to bribe? Who can actually follow through? Who can do it tactfully enough to not get caught in the act? Etc. Maybe not "computer hacker", but "organizational hacker" sure
I think the difference of opinion is whether or not you think on-paper democracy includes lobbying as a natural mechanism for law making and whether or not lobbying is, respectively, a workaround.
And this is why you should not make backend services accessible from the wide Internet, only from a 2-factor secured VPN or corporate internal network.
It's utterly amazing how many companies got hacked by this oversight.
How does that defend against a compromised employee which is the problem we're seeing here? If the employee was bribed into giving out his credentials he can very well be bribed to just do the dirty work himself if the credentials are unusable outside the corporate network.
Simple: because an Internet-accessible backend will always be a prime target for hackers. RCE exploits, API endpoints where the developer forgot or misconfigured the authorization checks, credential spoofing/phishing... keep that stuff on the real intranet and a whole class of attacks simply vanishes.
For small organizations isolating this stuff on an intranet makes sense. For larger organizations that is less valuable, as the intranet becomes less trusted. Some larger companies have done away with large portions of their intranet.
And a VPN isn't subject to exploits or misconfiguration either?
I'd much rather put my back office behind a 2fa in the browser than use a VPN, it's a far better user experience. Using an off the shelf reverse proxy or commercial solution mitigates to some extent the risk of developers messing up the auth, but both a VPN and proxy can be misconfigured.
I would argue that making sure a VPN is correctly configured is easier than making sure every single backend service is configured correctly and patched against all known vulnerabilities. Overall I think its best to keep those things on the company intranet and only accessible remotely via VPN, while further limiting the employee to have access only to the services they need on the network
Even better though, why not use both 2fa and locking such improtant services to the intranet or behind a VPN
The boundary between cyber criminal and smooth criminal has always been blurred. Consider the social engineering prerequisite for LOVE-LETTER-FOR-YOU.txt.vbs. No one remembers his other worms because nobody opens malware.sh.
Back in the days of AOL, before phishing became mainstream, it was all about getting the leetest screen names or wielding power over inferior "hacking" rivals. One of the easiest ways was to befriend college kids who worked as CSRs and eventually extract enough info to call in and reset the password. That eventually stopped working so well when AOL added auditing to their customer support activities. History repeats itself!
Do your threat models include your staff? Of course, nobody has admin access.
Do your threat models include your staff accessing restricted information that they need to access? How do you stop somebody from doing their job?
IME this is a great interview question to ask potential employers. The rabbit hole that you are required to go down will open eyes.
The answer is: you can't. But how you mitigate damage (with data silos) and engage in disaster recovery after the fact puts you in excellent condition to weather any storm.