Most people have encountered the cloud at work, whether it’s downloading files from an external business contact’s Dropbox or hearing through the grapevine that your department is now “moving” to a cloud service. Security controls in many of these initiatives is handled (you hope) by someone at the company who is setting policy about these rollouts and what types of applications and sensitive data can be placed in the cloud.
Turns out, that isn’t happening as much as it should. Shadow IT spending often may exceed 30% of IT budget spending, according to Matt Cain, research vice president at Gartner, who expects that number to go up because employees want applications and services before IT can authorize and support them.
This week Cisco is rolling out Cloud Consumption as a Service to help large to mid-sized businesses track their employees’ use of shadow cloud services. Cisco also offers consumption services through its global service organization.
According to Cisco, Cloud Consumption as a Service will help companies monitor public cloud services in use and better control data protection, cost and regulatory compliance. The software as a service (SaaS) enables companies to sort cloud providers by risk, remove redundant services and benchmark cloud usage to help CIOs gain control of costs, which are sometimes hidden. In addition to discovering shadow services and identifying who is using them; security professionals can create triggers and alerts to detect abnormal usage patterns. The cost of these services is $1 to $2 per month per employee.
Sounds like a good idea, but tracking cloud usage isn’t the only problem.
Many security professionals describe shadow IT services as “circumventing” IT and security teams. In some cases, that is probably true. According to Gigaom Research, 81% of employees admitted to using unauthorized public cloud services but only 38% deliberately avoided the IT approval process.
In many organizations, there is still no policy in place about public cloud services and how they should be handled at the company. Do you really need a tool to monitor cloud usage or a policy that IT and department heads can use as guidance for these cloud initiatives? The problem often isn’t circumvention or too much Red tape—it’s a failure to get policy and procedures (and bodies) in place in front of a coming storm. Virtualization machines that go unchecked; unpatched legacy applications that newbies on staff don’t really know how to fix; and now, with a mobile workforce that has moved beyond Sharepoint, the inevitable cloud sprawl.
When security questions come up in a department meeting about a cloud deployment and people look confused and say, “I think Joe in IT probably knows the answer to that question.” Turns out he doesn’t.
I try not to be too much of an alarmist when it comes to information security matters, because all things considered, the situation on a global level could be a lot worse. We could all be suffering from malware –induced power grid outages like the Ukraine, or experiencing stunning invasions of privacy like the poor souls who bought Internet-connected VTech toys for their kids and just didn’t know any better.
The latter situation is more troubling when viewed through the prism of the bright lights and drab histrionics of Las Vegas this week. The Consumer Electronics Show has never really been a home for information security companies, and having attended the show for several years in the past, I didn’t actually expect that to change this year despite the increasing number of enterprise data breaches. After all, CES is about gadgets and TVS and cool tech that people actually want, not need.
But I expected more than security highlights than an iris scan-enabled ATM from EyeLock, a wireless-enabled video security camera puzzlingly named the “Stick Up Cam,” and an Internet-connected home surveillance devices from – get this – VTech (!!!). When the most interesting infosec offering of the week is a “privacy guard” smartphone case that provides a Faraday cage around your beloved gadget, then that’s not exactly a great sign.
CES 2016 wasn’t a complete no-show for security. The show did, in fact, have an all-day cybersercurity forum this week with such speakers as AVG CEO Gary Kovacs, security reporter Brian Krebs and Trend Micro Chief Cybersecurity Officer Tom Kellerman. And with RSA Conference 2016 just around the corner, it may not have made sense for infosec companies to spend more time and money exhibiting at CES.
Still, a number of major tech manufacturers have made CES their launch pad for enterprise-focused offerings in the past, and that trend continued this year (just looked at how IBM promoted its Watson technology and PC makers like Dell, HP and Lenovo pushed their enterprise client devices). It seems like a missed opportunity for security vendors to cross over into such a high-profile event and promote the benefits of good infosec hygiene, to say nothing of the tech giants that were actually at the show that said virtually nothing about infosec (Hello, Intel).
I didn’t attend the show this year, and I’m thankful I didn’t have to make the laborious trip and daily grind that CES requires. But I would have gladly made the sacrifice just to see a few companies make serious attempts to put sound infosec technology in front of 150,000-plus people. But if we can’t get a stronger, more serious security presence at the biggest technology show in the world, then we’re doomed.
Whether or not you think Bitcoin has a future, it has a couple of very interesting technological elements that will probably have a life of their own. The aspect that everyone talks about is that Bitcoins derive their value by dint of being “mined.” It takes time, computational power, and a pretty hefty electrical bill to mine Bitcoins in any significant amount and it’s the difficulty of getting new ones (just like it’s the difficulty of getting “new” gold out of the ground) that gives the coins value. But a second, equally interesting aspect of Bitcoins is that there is a distributed transaction ledger system where the transactional history of each Bitcoin is vouchsafed for as long as Bitcoin is around and being used.
The distributed ledger part of the Bitcoin world is implemented by way of a “blockchain.” Actually, the money itself is all but indistinguishable from the blockchain. That a Bitcoin exists at all is because a root for the coin (the “coinbase”) is created when the Bitcoin is created and all subsequent transactions with that coin are recorded in the blockchain. Each transaction is signed by the appropriate party’s private encryption key and then written into the current ten-megabyte block of the overall blockchain.
Without trying to explain the mechanics of the whole thing, the point is that the blockchain that fuels Bitcoin is there forever – it will be there until such time as the system completely fails. And even then, the distributed nature of blockchains means that copies will be around. Again, without digging into the details, there are other blockchains out there and it would be at least theoretically possible to store and vouchsafe a master copy of a failed blockchain if it ever came to that.
So the Bitcoin blockchain is immutable and distributed. That’s great for Bitcoins, but it’s also great for some innovative startups. I spoke with Peter Kirby, the president of Austin-based Factom, who explained why it was also great for general ledger storage beyond just keeping track of coins.
Kirby told me that “the simplest analogy of how the blockchain works is I send you something–I send you a bit of information. Everybody in the room agrees and we write that on a brick. We put that brick in a wall and then we stack ten thousand bricks on top of it. Then we move on to the next transaction and we put that brick in the wall and stack another ten thousand on top of that. The blocks are transaction blocks and there’s a whole lot of effort, we call it proof of work, stacked on top of it to make it really, really, really hard to change that block.
“What we said at Factom is, well, there’s a whole lot of stuff in the world that doesn’t look like money transactions. What if we could do a blockchain for data. And it turns out that having permanent, immutable, tamper-proof data is a really big deal for anybody who does record keeping, anybody who cares about their data being written once and never changed and never tampered with.”
The ledger entries that a bank or an insurance company might write to the Factom system could, in theory, be written directly to Bitcoin blocks, but there’s only so much data that can be stored in a bitcoin block and writing large volumes would be expensive and impractical. Instead, Factom commits a very small transaction (it’s the top hash of a Merkle tree of all the transactions from the past ten minutes, if you want to be really geeky about it) to the Bitcoin blockchain every ten minutes and then uses cryptographic hashes to tie all the Factom writes transacted within that ten minute period to the Bitcoin blockchain.
When a blockchain of entries (these are what get hashed in the Merkle tree) within the Factom system is initiated, Kirby says, “I get to set up what the rules are about what goes in that chain, what belongs in that chain and who’s allowed to do it. Now I’ve got a way to program what the auditors allow in that chain. And I can say, hey, it’s got to have a date formatted a certain way, it’s got to have an ID, and so on.”
Writing to the Factom store (inherently a write-once operation) requires an “entry credit,” which is essentially a software license allowing the access for writing one record. Credit entries, in turn, are converted from a unit called a Factoid, bought with Bitcoins. When sales of Factoids opened last week, buyers got 2000 Factoids to the Bitcoin. In the first days of the sale, more than a million-and-a-half Factoids were sold.
Kirby says that “one of the things that the development team did that ended up being really useful in the business world is they separated factoids and Bitcoin and all the cryptocurrencies, all the digital aspects of it, from the entry credit. So a big bank that’s not allowed to touch Bitcoins, that’s not allowed to hold Ripple, that’s not allowed to hold Ethereum, none of that stuff—their lawyers won’t let them, can still buy entry credits because they’re non-transferrable, they don’t have monetary value, it’s purely a software license at that point.”
It’s still early days. The initial sale of factoids just creates the endowment for a Factom Foundation–a full, working beta of Factom remains some months away. The Factom Foundation is a nonprofit that develops and maintains the open-source software—it separates the blockchain and its mechanics from the process of creating applications on top of those basic infrastructure elements. While the appeal of an immutable data ledger is clear for many essential business verticles, how Factom makes money as a commercial operation is still to be sorted out.
Reporting by The New York Times notwithstanding, it appears to this non-lawyer that Hillary Clinton probably didn’t break any laws by using a personal email account to conduct state business. But legal or not, what should probably bother us all is that we can’t help but assume that there’s no way that clintonemail.com was secure. Because that’s a key concern here–we just can’t believe that state secrets could be safe in such an account.
The Times broke the story by saying that Clinton had not only made extensive use of a personal email account while Secretary of State, but that “Federal regulations, since 2009, have required that all emails be preserved as part of an agency’s record keeping system.”
It is neither clear that the requirements regarding email accounts were in effect in 2009 (or indeed, during the entirety of Clinton’s tenure in the office), nor that she failed to preserve the email messages (when the State Department requested the email last year, Clinton provided 50,000 messages).
The relevant law here, it would appear, begins with a memorandum to update an existing (1950) law guiding records management. The memorandum was issued by President Obama in 2011.
This directive didn’t change the rules, it simply called for the rules to be re-examined and updated. The National Archives and Records Administration (NARA) subsequently published their findings and proposed changes in August 2013. At that point, Clinton had been out of office for more than half a year. The NARA findings weren’t actually signed into law until 2014.
Nothing in the new rules (or the old ones) prevents a cabinet member from using a personal email account to conduct business, provided the records are kept and the emails are turned over to that cabinet member’s agency for preservation. And it’s been done before: Colin Powell used personal email for state business.
Legal or not, commentary on the Internet has been quick to say that using personal email is no way to treat sensitive national business. As a practical matter, that seems irrefutably true, though whether it’s equally true that the State Department’s email system is secure is, I’d say, an open question. Certainly their system for diplomatic cables had its rough edges.
But why is it so obvious or inevitable that a personal mail account is insecure? Email is, frankly, a pretty straightforward system. And yes, certificate management is a tricky subject that complicates encryption, but I see no reason why major providers of personal accounts couldn’t issue basic certifications as part of creating an account. This wouldn’t mean that messages coming from that account weren’t fraudulent (because the real identity of the account holder would presumably remain unverified), but it would mean that if I sent you a message encrypted with those keys, nobody else would be able to read it, give or take the NSA.
Hillary’s team didn’t lack for means and I suspect she has some pretty sharp people handling her IT. But somehow we’ve been concerned about computer security for a quarter century and we have no faith at all that she couldn’t set up her own secure email. Now there’s something that ought to be against the law.
A lot of what went on at the White House Summit on Cybersecurity and Consumer Protection, held at Stanford University last week was for show — a reaction in particular to the attacks allegedly carried out by North Korea against Sony pictures. Like any live event, was also clearly some desire to get lots of the right people in the same room news reports pointed out that several of the right people, including the CEOs from Google and accept checks, opted out.
But this was also an event where the President took the time to show up and deliver a speech. Furthermore, President Obama made a point of publicly signing an executive directive, creating an air of something happening. The sound bite for what was going on, the way that the broad market media covered it, was that this directive encouraged sharing of cyber security threat information between the government and the private sector.
It’s worth noting that most of what the order calls for already exists in one form or another.
The organization traditionally tasked with combating cybercrime as the FBI, though the DHS increasingly seems to think it’s their problem, or least that it’s their problem to detect incipient attacks and help build up private-sector defenses (since most of the infrastructure that makes up the Internet is in private hands). Presumably it’s still the FBI (and local law enforcement) that crashes through a hacker’s door and impounds their electronics before they can be wiped.
The FBI funded a nonprofit organization, InfraGard, to link US businesses to the FBI all the way back in 1996. Aside from the FBI efforts to foster cooperation, there are a number of information sharing and analysis centers (ISACs) for different industry verticals that were funded as a result of a presidential directive issued by Bill Clinton in 1998.
Since ISACs are still motoring right along, you could be forgiven if you found yourself wondering about the difference between an ISAC and an ISAO (information sharing and analysis organization), which is what Obama’s directive calls for.
As it turns out, there may well be no difference between an ISAC and ISAO, according to a fact sheet that the White House published alongside the directive. ISACs can be ISAOs, though they may have to follow somewhat different rules if they are, insofar as the directive also calls for a nonprofit agency to create a “common set of voluntary standards for ISAOs.”
Perhaps the key element lurking in the directive is the idea that this network of ISAOs, connecting to the National Cyber Security and Communications Integration Center (NCCIC) to foster public/private sharing, creates a framework that could serve as a reporting channel companies could use to gain protection from liability when reporting security incidents. This idea of liability protection for companies that share comes from legislation proposed by the President in January. It’s unclear whether Congress or the American public as much stomach for letting corporate America off the hook for leaving their barn doors open.
For the time being, though, just remember that an ISAC and and ISAO are probably the same thing. It’s just that now there’s going to be a whole lot more sharing going on for reasons that, well, aren’t entirely clear.
Though I’ll admit to a bit of skepticism about Runtime Application Self Protection (RASP), I was nevertheless impressed with a recent look at Prevoty. The two-year-old company’s product, which currently has support for Java and .NET Web applications and services, can be dropped into production systems without recoding being required, uses a separate server (either on premise or in the cloud) to do the heavy compute parts, and seems to have a smarter-than-average approach to determining the application context in which requests (such as SQL queries) are made within the running application.
Getting the context right is important in RASP, because otherwise you’re more or less just melding the brains of a web application firewall (WAF) to each of your applications—to no particular advantage over just using a real WAF. Nor is context all that easy to get. It’s not simply a matter of scanning the code or scanning user input on the fly, and Prevoty does no static scanning or signature hunting, according to Prevoty CTO Kunal Anand, who started his career working on Mars rovers at NASA, moved on to build and run the security team at MySpace, then graduated to be the technology head for BBC Worldwide.
Like some other RASP products (Arxan’s, for instance), Prevoty can either be used in a completely automatic fashion, where programmers don’t have to change a single line of code. “They’re simply including the Prevoty JAR files and adding it to the XML file for execution,” Anand explains.
There’s also an SDK approach where developers directly call Prevoty functions at appropriate moments in the control flow of their applications.
The automatic approach offers both a passive learning mode and a mode that will take action when problems are detected. The passive mode, being asynchronous, does not impact the normal performance of the application. The active mode’s performance impact depends on whether the deployment is using an on-premise engine or the cloud engine. If it’s on premise, Anand says customers are seeing round-trip times between app and engine in the range of one to two milliseconds. Cloud users see round trips of 20 to 40 milliseconds. Processing at the engine takes seven milliseconds.
With Black Hat’s conference in Singapore coming up next month, I found myself chatting with independent security researcher Nitesh Dhanjani, who’ll be giving a presentation at the March 25-28 event. We talked mostly about some things he’d learned about the Philips hue lightbulb system. These LED bulbs, one of the hipster gems lurking in accessory section of the Apple Store, are a fancy, Internet-connected product, squashed full of wireless circuitry. Among other things, you can use your iPhone to set them to one of 16 million colors (and these days, I should add, you can do this from an Android app as well).
The magic works because the lightbulbs talk in the Zigbee home automation wireless protocol to a base unit that acts as a bridge between Zigbee and Wifi. Your smartphone controls the lightbulb essentially by using an app that browses to a Web server running on the base unit.
There’s a security feature that Philips has incorporated – your smartphone won’t be able to send control commands through the base unit unless it’s been pre-registered. To carry this registration out, you’ve got to use the local Wifi connection and you have to first press a button on the base unit (setting the unit to an open registration mode for a few minutes).
Partway through his research, Dhanjani noticed a quirk in this security feature after he’d had to completely reload his phone’s operating system and a fresh, unconfigured copy of the app.
The thing was, TK had been forced to completely reload his phone’s operating system and to load a fresh, unconfigured copy of the app. “I was walking over to my bridge, where I needed to press the button and it just worked. So I thought, how does the app know? Because I’m supposed to press the button. I thought, it just has to be something that ties to the phone.”
Long story short, the app sends a hash of the phone’s Wifi MAC address. If you’ve got access to the Wifi network, you’ve got access to the MAC address and getting the hash value is trivial. So, imagine a virus that attacks a conventional endpoint on your home network, but then turns off your lights and just keeps looping to turn them off.
Fatal? That’s probably too dark a view of the matter. But it’s more proof, if you needed it, that the Internet of Things will repeat the security mistakes of ten years ago.
Ran across the Fortune 1000 Cyber Disclosure Report, published earlier this month by Willis North America, a unit of Willis Group Holdings. The report found that among the Fortune 501-1,000, 22% remained silent on cyber risk. A “significant” increase compared to 12% of the Fortune 500 firms who remained silent in their disclosures, Willis said.
- The top three cyber risks identified by the Fortune 1,000 include: privacy/loss of confidential data, reputation risk and malicious acts.
- Cyber terrorism and intellectual property risks ranked lower than expected among the Fortune 1,000 given the focus of the federal government on these areas of risk and their importance to the health of the U.S. economy overall, the report said.
- When describing the “extent” of cyber risk exposures, financial institutions and technology companies rise to the top of the list disclosing distinct cyber exposures. Meanwhile, firms in the energy and utility sector report the fewest distinct exposures.
- In evaluating loss control measures, the industry groups that disclosed the greatest number of technical protections against cyber risk, including firewalls, intrusion detection, and encryption, include the technology, health care, professional services and financial institution sectors. Within financial services firms, insurance companies refer to technical risk protection 63% of the time.
- With respect to cyber insurance protection, the funds sector (33%) followed by utilities (15%), the banking sector and conglomerates (14%) reported the greatest levels of insurance. Insurance and technology sectors both disclosed the purchase of insurance coverage at the 11% level. However, the report indicated that many companies may be under-reporting the level of cyber insurance coverage based on Willis data and other industry data indicating higher take up rates, particularly for the health care sector.
- The disclosure of actual cyber events remains at 1%, a seemingly low number given the number of attacks that appear in the press on a regular basis, the report said.
Out in the last few days is an interesting quarterly update report from McAfee.
Topline findings from the second quarter of the year include the following:
- Banking Malware. Malicious parties employ mobile malware that capture usernames and passwords, and then intercept SMS messages containing bank account login credentials to directly access accounts and transfer funds.
- Fraudulent Dating Apps. These apps dupe users into signing up for paid services that do not exist. The profits from the purchases are later supplemented by the ongoing theft and sale of user information and personal data stored on the devices.
- Weaponized Apps. These threats collect a large amount of personal user information (contacts, call logs, SMS messages, location) and upload the data to the attacker’s server.
- Ransomware. The number of new samples in the second quarter was greater than 320,000, more than twice as many as the previous period.
- Attacks on Bitcoin Infrastructure. In addition to disruptive distributed denial of service attacks, victims were infected with malware that uses computer resources to mine and steal the virtual currency.
That last bit, the Bitcoin bit, was kind of interesting, in that the whole Bitcoin kerfluffle has completely fallen off the radar in a remarkably short amount of time. There’s a nice timeline in the report to refresh one’s memory–and I suspect we’ll here more about Bitcoin someday fairly soon. On the other hand, it didn’t seem like McAfee could offer any information that was already generally reported in the news.
On a typical Web page, it’s possible to load a script from another file. Typically, that bit of script will be something you, the site developer, will have put there yourself and it will be loaded from your server.
But it doesn’t have to be that way. It’s possible to load that script from just about anywhere and it’s also possible that someone malicious could use an input field on a form at your site to inject some scripting, or at least a call to invoke a script from elsewhere.
Since that injected script is probably up to no good, it would be nice to ensure that it can’t run. And that’s where the HTML Content Security Policy header comes in. As a new entry on the Neohapsis blog puts it:
CSP functions by allowing a web application to declare the source of where it expects to load scripts, allowing the client to detect and block malicious scripts injected into the application by an attacker.
Sounds good, right? But the Neohapsis folks have found that really getting a handle on CSP takes some practice and some experimentation. So to facilitate this, they’ve created the CSPplayground, which includes a number of things, but in particular includes a bunch of examples of CSP screwups.