Think server vulns are the IT department's problem? Think again Regardless of the type or size of business you're part of, the way we approach security has changed forever. Gone are the days that a business can feel safe with its security design model. Attacks have become more sophisticated. Your organization should no longer be thinking about “if” an attack will happen, but be planning …
I agree, I'll forward it to my wife to try to get her to understand but she'd just ignore it as 'tech speak'. Unfortunately with running her own business she needs to understand that she is responsible to her customers, I hope it doesn't take a breach or loss of service to make her understand this.
Don't forget protective monitoring.
If you're not logging effectively and not looking at those logs then you may never know you've been compromised or if you do find out you might never know how it happened.
If you don't know what door was opened how do you know where to put the locks?
The aviation industry is currently pondering a version of aviation ICMP, after MH370. Planes will ping ground centres every 15 minutes or so.
Outside of north America, it seems that there is no regulatory requirement for the operator of the plane to be in contact with it at all. Not a coincidence: airlines are under pressure to reduce recurring costs like people, because we refuse to pay $20 more for a ticket. My source tells me that what is in danger of being promulgated is a requirement to log aircraft movements without a requirement that there is someone to read the logs.
So, you can log all you want, you'd better have actual people to read them. Those people had better understand what they're looking at, and be able to take action when something goes wrong. This might cost you actual money.
Much like using CCTV's' for physical security. It's not about catching things in the act, it's about the fallout afterwards. In someways this is proper and right and in other ways, it's very bad. Periodically going over the logs is a good idea just as having someone eyeball the tapes (even if just in fast forward) is a good idea. Just because an alarm wasn't tripped doesn't mean that something "not good" is going on.
"Use more than one technology: A single vendor cannot cover everything and represents a weak link in your security chain."
For security products perhaps; but the inverse is true for the rest. If you only run e.g. Windows, your network will only be exposed to its vulnerabilities; whereas if half the office has Apples or *nix variants, your network is exposed to all their foibles too. Same applies if e.g. half the company uses Chrome and the other half uses Firefox.
While you might think that is a good idea, its not really as then your IT folk are unlikely to be good at all of the systems.
Sure, chose the less-attacked OS if you can (i.e. you can get matching applications that work for you) but you really need to concentrate on:
1) Having someone (internal or contractor) who is good at their job and looks after things. For example, having someone who really knows Windows and is allowed to lock things down will be better than a monkey who thinks they know Linux, even if the attack statistics point the other way.
2) Keeping stuff patched as far as possible.
3) Having an isolated backup that you KNOW you can recover when its needed (i.e. something that randsomware can't also encrypt because its not visible as a file system to normal computers).
4) Training staff not to do dumb things and, more importantly, if they do make a mistake or suspect something odd is happening to get it dealt with immediately and not pretend it never happened.
My 2p worth.
4) Training staff not to do dumb things and, more importantly, if they do make a mistake or suspect something odd is happening to get it dealt with immediately and not pretend it never happened.
This is possibly the most important and most difficult thing to accomplish. It's been a while now, but I still recall one receptionist we had. No matter how much we emphasized that she should keep her password on a piece of paper under her keyboard, that was always where you'd find it. "But there's nothing valuable that I have access to" was always her response. She was a nice lady, otherwise very competent at her job, set in her ways, and nearing retirement.
Of course for the rest of us, the insanity of the interactions of security policies forces us to do similar things. Having 15 passwords of varying lengths, different rule sets, and different intervals for changing them pretty much guarantees one of your users will have a sheet of paper with all their passwords written down.
The challenge here is the time and effort required to do this for ALL the components of system.
Take for example a web server, running dot net code - it's not just the o/s that needs patching, it's the dotnet framework, which means not just hotfixes but service packs. Then what about the fact the o/s needs service packing, in order to get the patches. Then consider the version of dot net becoming out of support and requiring upgrade. This means application code testing and code changes.
Add in patching the server hardware - the firmwares of the BIOS, disk controllers, NIC's, FC cards, remote hardware controllers, the disks and more... each of which will have version dependencies on each other.
Then add in the hardware drivers - these will need updating once the firmware(s) are done, again with dependent on specific versions for specific firmware and specific o/s patches and version.
Oh - and don't forget all those 'standard' applications you have installed - the backup software, the anti-virus software, the monitoring software and more - all of which will requires their own hotfixes, patches, version upgrades - all using different update mechanisms.
Same goes if this were a Linux / Apache web server - it's not just a challenge for windows platforms
Then you've got to look at patching the rest of the supporting infrastructure - the switches & hubs, the routers, the firewalls, the storage infrastructure, the backup infrastructure.....
And all of that's just for one web server hosting one bit of application code.
This is why maintaining security is a significant task - requiring significant investment in skilled people and process and testing even if you are able to leverage smart deployment tools and automation to help.
While I agree with what you're saying, a minor correction: "all using different update mechanisms" isn't really true for Linux. Generally Linux will update from the distro repository which contains updates for *all* software in the distro, not just the OS itself. Usually it only takes 1 command to update everything (not including hardware firmware and the like, but installed software at least).
And then you have to deal with the systems that the suppliers refuse to update or want to bill you for.
Plenty of government department and businesses running vulnerable versions of Java and out of support servers because their essential software hasn't kept pace and contracts don't insist on it.
Then you have to deal with the meat layer which at the bottom is thick and uninterested in awareness/education but very interested in penis pill spam and at the top execs that want to have the latest exec fashion in technology irrespective of any business case or impact on the rest of the business.
Good article, especially in highlighting the scope outside of strictly IT. As was mentioned with aviation, physical security (access control, video surveillance) should be included in this more because there are more and more cases where that is used to gain the insight needed to overcome logical security. For reference, look at the Carbanak malware-based bank heist where video was hacked in order to learn from observation how things worked inside.
The security team within your IT department cannot standalone...
In all of the places I've worked, the reason the security team stands alone is because they choose to. I understand the reason: they're like sort of like internal investigators for the police, they have to suspect everybody. Still, that doesn't build the teamwork you need for the emergency response. This assumes of course that your security team is actually competent and not merely looking at 6 month old logs then issuing demands like the threat is current.
The article just rehashes all the talking points that those of us in InfoSec espouse and that falls on death management ears. Management just doesn't want to spend the money, generally speaking. And when they do, they think that they can just throw money in an IT pot and magic will come out without any follow through, day after day, year after year.
My personal thought is that we as InfoSec professionals - who really "get it" - need to be more adept at selling our ideas to MBA types that run the company. In some ways, I think we as a whole must be failing to a certain extent, when we go to get "buy in" on our ideas. Supposing we have a good case for some security measure, hiring of more employees etc., we need learn to speak the business language of these MBAs in order to get our point across...prior to the exposure and loss of critical data. Anyone can be convinced to increase IT security after a hack and loss occurs. As an aside, maybe we InfoSec folks need to hone up on our business skills so that we are the best candidates from senior management and HRs point of view when it comes to putting in place the next manager over IT/IS assets...we need to fully understand that which the MBAs do in order to talk the talk with them when it comes to management of folks - so called, "soft skills" - , finance etc.
An excellent way to hone up on business skills and speak the same language as the MBA types is, of course, to study for an MBA and become an experienced manager. I consider my MBA the best information security qualification I hold. I also heartily recommend CISM from ISACA which emphasizes the governance angles of our job, plus risk management, compliance, business continuity and other stuff that IT security (and "cybersecurity") pro's tend not to appreciate. There is MUCH more to being an effective information security pro than knowing about vulnerabilities in IT systems.
[By the way, "death management ears" tickled me. Freudian slip?]
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
