You're the IT worker in charge of securing the cloud for your company. Welcome to Hell Once upon a time, you’d go into the office, do your work during the day at your desk, then leave everything behind and go home. Well, end users would - IT workers have been lugging home the on-call laptop since the dial-up modem was invented. Back then, securing the information and the IT assets of a desk-based workforce …
Panasonic Sr. Partner. 38 pounds of luggable (including case, modem, manuals & floppies). At least it had a built-in printer. I still have it. You get attached to the daftest things after a quarter million air-miles together.
It has an MFM controller in the expansion slot, a 20 meg hard drive in one of the floppy bays, and an aftermarket hack that upped the stock 256K of RAM to a more usable768K. I used an external modem. Yes, it still works. Came with Panasonic-labeled MS-DOS 2.2, but it currently boots MS-DOS 3.3 ... It might be hard for some of the younger readers to believe, but a LOT of RealWorld[tm] work was done with such primitive devices.
If your employees want to access the data from home, just setup a VPN and let them log in from home via ssh using public key authentification. That's both secure and easy to do.
It's only when you made the error of installing Windows PCs that it gets hard. You cannot (usefully) ssh into a Windows box and use your standard text editor or e-mail software.
SSH doesn't just mean a text terminal. You can use it to tunnel through multiple hosts to get to your endpoint very easily, basically a simple VPN solution, especially when used as a SOCKS proxy.
Organisation totally locked down from the outside? SSH out to a friendly host and create a reverse tunnel for whatever service you need (within reason). Bang - you've got your entry point for working on the move!
Indeed, as an infosec person for quite a while, I tried that one out in 1997 with a reverse telnet session going out through a SOCKS firewall. Catching people doing that sort of thing and arranging for them to have a little chat with Employee Relations (after having confirmed it wasn't an APT) became easier a decade later with decent log analytics like Splunk.
Tarantella was all about tunnelling X11, RDP and VT apps via a known, graphics-optimised (and at the time optionally SSL encrypted) port into a Java applet in a web browser. Great idea, decent product, poor marketing plus head-to-head against Citrix. Eventually bought buy Sunacle and still available as Oracle Secure Global Desktop.
For those of us tasked with securing environments from such frivolities, there is no SSH out permitted from users' workstations, nor HTTP/HTTPS/DNS/NTP, that stuff goes either through explicit proxies, secure recursive DNS servers and services, and on-premises timeservers.
All SSL traffic sans banking and medical is decrypted, its payload analyzed and PCs behavior checked for anomalies.
"You cannot (usefully) ssh into a Windows box and use your standard text editor or e-mail software."
No argument there. If the users are only using text based stuff then SSH is fine.
Companies using Windows have this thing called RDP which allows the users to use their ERP, Office programs ("standard editors") and email software which I reckon is probably not going to be elm or pine in most businesses around the world.
It's just progress. As soon as security professionals have managed to get a grip on one type of vulnerability, like say, USB, it has been necessary to introduce some brand new means of making stuff insecure all over again. "Cloud" is, I admit, a bit transparently OTT—imagine selling it by saying "Only some of your data on individual desktops was at risk before, or on chips people lose on trains: but now we can take all your vital data and put it somewhere public for truly industrial-scale insecurity!"
But, hey, convince some greedy boardroom idiots that they can score a bonus because of "cost savings", and they will fall for anything. By the time the "cloud" or outsourcing or latest buzzword-bolox-initiative has crashed, burned and consumed twice as much as it was supposedly going to save, those same idiots will be in a new job, f**king up a new company.
The beauty of "cloud" of course, is that it greatly reduces the workload of those poor, hard-pressed guys who write exploits and malware. Whereas they might have had to work at tailoring and socially engineering each individual bit of industrial espionage for every business they were trying to rape, "cloud" provides a much nicer one-stop-shop so that vast amounts of data can be stolen or corrupted at a fell swoop.
As any self-respecting parasite would say: "Long live the monoculture".
PS: And in other news for paranoids ;-) ... No doubt the enterprising folks whose business is to steal on an industrial scale are working hard just in case the "cloud" providers (and their chip manufacturers) actually secure things better. Even as we speak, a new generation of submarine drones is sniffing around on the planet's seabeds, ready to clamp their lamprey interfaces on to barnacle-encrusted cables, thereafter to sop up petabaytes of data every second. (And with some scissors handy too—just in case this or that nation-state/bidder fancies cutting off the continental internet for a month or two.)
If you were to implement (and enforce) all those security measures listed in the article can anyone provide a rough estimate as to the cost? (licences & support & training etc.).
I've got a funny feeling that it will end up being more expensive than keeping everything in-house and triage your risks with basic access policies before spending millions on the detailed stuff.
I'm fortunate in that I design environments for security people to work in, so if they aren't prepared to jump through a few hoops to gain access then they aren't in the right job in the first place, so it doesn't really happen. I feel for the people who are designing for 'users' and using the 'cloud'.
Seriously, the threat landscape has changed so much in the last 10 years (and is continually evolving much faster than the tools to combat them) that it's a real challenge to secure an environment that you have *full* control over. After all, at some point people have to *do* stuff, and that's where lots of the risk comes from, controlling who does what etc. and also how to stop trusted people taking advantage.
Disgruntled employees are still a major risk, and in certain situations you can expect infiltration to be a factor too.
Of course, a lot depends on the value of the data you are protecting, but the higher the data value the more likely it is that you won't be putting it anywhere near a cloud, no matter what the short-term financial advantages are.
"Of course, a lot depends on the value of the data you are protecting, but the higher the data value the more likely it is that you won't be putting it anywhere near a cloud, no matter what the short-term financial advantages are."
Not even under a DIE order from up top?
Not even under a DIE order from up top?
No. In fact I managed to have the fundamental design changed because the SA that started the ball rolling hadn't realised that parts of his idea were simply not securable.
If you don't have the authority to enforce decisions, you have to provide sufficient evidence that one idea is not good whilst providing alternatives that are better, along with their pro's and con's.
Delivered in the correct way, this usually results in a decision that is justifiable. It's ok to make the odd mistake as long as you had given the matter proper thought and made the best decision you could for the right reasons.
Knee-jerk reactions, or JFDI's (or DIE's) are not justifiable, especially when there is an external regulator with sharp teeth breathing down your neck.
"Knee-jerk reactions, or JFDI's (or DIE's) are not justifiable, especially when there is an external regulator with sharp teeth breathing down your neck."
You're lucky, then. It's another thing altogether to have higher-ups breathing down your neck as well and no ships in sight to which to jump.
I hear what you're saying, and I've certainly been in those situations.
However, as long as nothing of consequence is at stake (such as National Security or CNI etc.) and I have made the risks and impacts clear and the jfdi still stands, then they pay me to implement their crazy ideas I suppose.
The hardest part for me in that kind of situation is staying focused and still trying to do the best I can even though I know we're piling on the coal straight towards the ice-berg. I try and reinforce the hull along the way so to speak, but not to the point where I'm risking my health.
I just usually try and avoid those situations if I can.
And that's why we have Security Architects, to work out how in the requirements capture and design phase of the project to mitigate risks as far as operationally possible and for lowest possible budget while enabling the operational business requirements in alignment with TOGAF design criteria.
You do all do it that way...right ?
This post has been deleted by its author
Remember though that, ultimately, it falls to the business side of your operation or to managers to decide where they want to draw the lines. They may retreat into: “It’s too hard, no personal phones for you”, or: “It’s all too expensive, we’ll just wear the risk.” If that happens, at least you told them
My "told you so" report draw is getting abit on the full Side ....
"IT workers have been lugging home the on-call laptop since the dial-up modem was invented.
Back then, securing the information and the IT assets of a desk-based workforce required a pretty simple architecture - secure the network, the internet, the email gateway, the server and the workers' device."
---------------------------------------------------------------------------------------------------------------------------------------
Dial-up modems were in use before there was an internet, or servers, or laptops, or microprocessors or email gateways.
Originally they were used for time-sharing applications using teletypes running at 110 baud. Connection was made to a mainframe, over a phone connection directly to that mainframe. If you wanted to talk to a different mainframe, you dialed a different number.
Speeds took a jump when the IBM 2741 came along, operating at 134.5 baud and about 13.5 characters per second. The 2741 was a small desk with a large electric typewriter built into it, and a couple of cubic feet of circuit boards built into the back of the desk. I expect it weighed on the order of 50 kilos (110 pounds}.
At that time dial-up modems were connected to the phone network either by an acoustic coupler or by being permanently wired into a dedicated phone circuit. Not all modems were dial-up, some were wired into dedicated networks and lines connected to a specific mainframe.
Modem speeds continued to increase as terminals became faster. The Diablo HyType 1 printer, which came from Xerox in 1973 was used to build very fast terminals running at 300 baud and 30 characters per second. These were about the size and weight of a 2741.
The first portable terminal I recall was based on the IBM Selectric mechanism, and was the size and weight of a large electric typewriter, plus more space for circuitry. Obviously, this was back to 134.5 baud, and used an acoustic coupler in order to connect to the phone system in multiple locations.
In the early days of dialup networking, email only worked for people dialing into the same computer. If you were working for a large company or a service bureau, this could result in email spanning continents, to a select group of colleagues or customers.
Somewhere around the transition from 134.5 baud to 300 baud modular phone jacks began to appear, making it easier to connect a modem, and allowing for setups with non-dedicated lines. By then the 8 bit microcomputer had appeared, and you could have a machine that was the size of a medium microwave, with only half a dozen circuit boards plugged into the motherboard. This wasn't all that portable... the first really portable machines were on the way, however.
By that time, there was a certain amount of networking going on, spearheaded by the military, universities, and tech companies. Email was no longer a 'this network only' or 'this computer only', and if you had an appropriate connection, and a bang path to your intended recipient, you could send email to tens or perhaps hundreds of thousands of people. On the other hand, you had to know the bang path, at least as far as a system that knew how to forward mail to the recipient's mail host.
In the early 1980s, machines like the Kaypro II (13 kg / 29 lb) and Osborne 1 (only 10.7 kg / 24.5 lb) provided powerful 64kb computers that could take full advantage of dial-up connections for portable applications. Speeds continued to rise, first to 1200, then to 2400 baud.
By the end of the 1980s, some machines were being built with a weight of around 3 kg - arguably the first 'laptops' by our current concept... many years after the dial-up modem was in widespread use... but trust me, no one was taking 2741s back and forth between home and work, in the back of their truck.
As for securing the network, that was done adequately with a login password. Malware did not yet really exist as a network phenomena until the late 1980s.
If a users device can view the confidential information at home then the data can be copied by a camera pointed at the screen. This totally bypasses any copy/paste restrictions in the software.
Disgruntled employees with home access to confidential data is a certain route to the data being extracted.
Two possibilities.
One - no offsite data access
Two - treat your staff well enough that they do not want to steal data
With most management option 2 is far less likely than option 1.
"Then along came the cloud. Our DMZ architecture world was rocked."
The cloud doesn't have anything to do with it. The DMZ architecture was already rocked at the point where people could click on E-mails and download malware onto their PCs. There *is* no secure perimeter.
You have to:
1. Authenticate all services at the level of individual users and devices - not the IP address they are connecting from
2. Do everything possible to prevent devices from getting p0wned: e.g. periodically scan devices for correct patch level and/or malware, issue time-limited certificate when this has been done; lock down devices to prevent users installing or running untrusted applications.
3. Detect abnormal patterns of activity and react to them promptly
4. Minimise allowed *outbound* Internet connectivity from servers
I don't suppose there is a single company in the whole world that could legitimately guarantee they achieve that, especially if there's a sufficiently well resourced bad hat to offer generous bribes.
OTOH there are no doubt millions of managers that would claim that's a legitimate strategy that they successfully operate.
In practice your No 2 is another variation of making nice noises, crossing your fingers and hoping someone else gets hit - always a popular security strategy.
Treating your staff well has an important role in reducing the threat, but never kid yourself it will eliminate it.
"Instead, we have to resort to pastebin.com."
!!!
reminds me of something that happened at a microsoft developer conference back in the 90's.
MS put a bunch of computers all over the halls, with NT 4 on them. I noticed that most of the command line stuff (including CMD) were disabled. But there was some demo software available and I wanted to mess with the sample code (some HTML pages) when I got home [the conference was in my home town]. So I ran FTP from the start menu, and FTP'd a couple of files to a web server. That is when I discovered that the '!' command in Microsoft's console mode FTP client got you a shell. I went into it, snickered, then exited. I'm not sure if I was "seen" or not, but it stopped working by the next day...
yeah, someone blocked copy/pasta to the host via the clipboard in the RDP client. Let's just use a pastebin instead!
Without blaming millennials, our society expects to access information fast and in a manner that’s convenient. That behaviour is seen in our customers and in our workers. Whether it’s a self-service portal to change your address, an account with your personal details for ordering from an app, or just the ability to check work emails on the train from your own phone, we’ve changed our definition of “remote access.”
Who has an expectation of checking work e-mail from outside the office? My expectation is that I don't check it, but it seems fewer and fewer jobs will allow you to (not) do that. It's of utmost importance to stay on the hamster wheel.
"Workers see mobility as the freedom to work anyway, at any time. "
Well, this worker doesn't see that as "freedom" at all. Unacceptable contract stipulations is a polite way of putting it. This attituda sums up my whole objection to the cloud thing - be "at the office" 24 hours a day, in order to sort out problems that could occur 24 hours a day. I'm more into using to tech to reduce the number of hours I have to work, not expand them.
"Well, this worker doesn't see that as "freedom" at all. Unacceptable contract stipulations is a polite way of putting it. This attituda sums up my whole objection to the cloud thing - be "at the office" 24 hours a day, in order to sort out problems that could occur 24 hours a day. I'm more into using to tech to reduce the number of hours I have to work, not expand them."
That may be what you want, but remember that the owners/board/executives get the final say, and if ALL of them demand 24/7 on-call access, all you can do is either bend over or jump off, realizing there may be no bottom down there.
Because you can scale to any size in the cloud (e.g. AWS). The sad reality is that it will cost the company a lot more and will be less secure and each node will be less reliable.
The old guard knows better than to go into the cloud but that is not how companies are funded - why would a company ask computing experts how to do something when they can just flannel the investors with buzzwords?
I am, I don't put anything that is not in the public domain in the cloud. CDN's do have their uses.
Out of office workers VPN into a private network. No third party has any of our confidential information on their severs.
"... so they could work from free Wi-Fi at trendy cafes."
I just don't get that: insecure and inconvenient. Easier for the user & safer for the business to provide staff with laptops or other devices with 4G connectivity built in. Have been using that for the best part of a decade now in my microbusiness. Easier than using a 4G dongle or MiFi (can get mislaid or run out of charge), better than tethering to your phone (drains the phone battery). Or have I missed something?
Problem is, laptops with 4G built in seem to be scarce these days: all I can find is HP or Dell models which are barely more powerful than my 4-year old Tosh, but double the price :(
(First used something like that close to 20 years ago, Nokia mobile phone connected to my laptop by cable, running at 9600 baud, on a hill above Rosedale Abbey.)
"Your mileage may vary, because there are some financial and government systems that will never be (or at least should never be) anywhere near the internet."
I believe, perhaps, you've missed the AWS (US-Only) Secret Cloud? (not a joke)
https://aws.amazon.com/blogs/publicsector/announcing-the-new-aws-secret-region/
...Your mileage may vary, because there are some financial and government systems that will never be (or at least should never be) anywhere near the internet....
Try designing a system without any standard parts like routers, switches and firewalls. Because all of these are by default remote maintained.
OK? Now, how do you maintain these new isolated boxes you've just designed? That's right - you bring in software, updates and a machine from the outsilde. Which has been connected to the internet...
Unless you dig your own sand to make your own silicon for your own processor on which you run your own firmware... all maintained by a bunch of cleared engineers and technicians locked in your own secured facility... you are going to have to interact with the outside world at some point....
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
