The rise of blockchain-as-a-service

With the announcement last week of the Enterprise Ethereum Alliance, it is timely to look at what is going on with blockchain technologies. The Alliance was formed to try to encourage a hybrid kind of blockchains with both public and private aspects. Its members include both cutting-edge startups along with established computer vendors such as Microsoft and major banks such as ING and Credit Suisse. As mentioned in this post by Tom Ding, a developer at String Labs, the Alliance could bring these disparate organizations together and find best-of-breed blockchain solutions that could benefit a variety of corporate development efforts.

When Bitcoin was invented, it was based on a very public blockchain database, one in which every transaction was open to anyone’s inspection. A public chain also allows anyone to create a new block, as long as they follow the protocol specs. But as blockchains matured, enterprises want something a bit more private, to have better control over the transactions for their own purposes and to control who is trusted to make new blocks.

This isn’t a mutually exclusive decision, and what is happening now is that many blockchain solutions use aspects from both public and private perspectives, as you can see from this infographic from Let’s Talk Payments.

You want the benefits of having multiple programmers hammering against an open source code base, with incentives for the blockchain community to improve the code and the overall network effects as more people enter this ecosystem. You also gain efficiencies as the number of developers scales up, and perhaps have future benefits where there is interoperability among the various different blockchain implementations. At least, that is theory espoused in a recent post on Medium here, where R Tyler Smith writes: “One thing that blockchains do extremely well is allow entities who do not trust one another to collaborate in a meaningful way.”

The Ethereum Alliance is just the latest milepost that blockchains are becoming more potentially useful for enterprise developers. Over the past year, several blockchain-as-a-service (BaaS) offerings have been introduced that make it easy to create your own blockchain with just a few clicks. Back in November 2015, Microsoft and ConsenSys built the first BaaS on top of Azure and now have several blockchain services available there. IBM followed in February 2016 with their own BaaS offering on BlueMix. IBM has a free starter plan that you can experiment with before you start spending serious money on their cloud implementations. Microsoft’s implementation is through its Azure Marketplace. There is no additional charge for blockchain services other than the cloud-based compute, network and storage resources used.

IBM’s BlueMix isn’t the only place the vendor has been active in this area: the company has been instrumental in supporting open source code regarding blockchain with large commitments to the Apache Hyperledger project. Not to be left out of things, the Amazon Web Services marketplace offers two blockchain-related service offerings. Finally, Deloitte has its own BaaS service offering as part of its Toronto-based blockchain consulting practice.
If you want to get started with BaaS, here is just one of numerous training videos that are available on the Microsoft virtual academy that covers the basics. There is also this informative white paper that goes into more details about how to deploy the Microsoft version of BaaS. IBM also has an informative video on some of the security issues you should consider here. (reg. req.)

Security Intelligence blog: Making the Move to an All-HTTPS Network

Many website operators have wrestled with the decision to move all their web infrastructure to support HTTPS protocols. The upside is obvious: better protection and a more secure pathway between browser and server. However, it isn’t all that easy to make the switch. In this piece that I wrote for IBM’s Security Intelligence blog, I bring up the case study of The Guardian’s website and what they did to make the transition. It took them more than a year and a lot of careful planning before they could fully support HTTPS.

Block that script!

It used to be so simple to understand how a web browser and a web server communicated. The server held a bunch of pages of HTML and sent them to the browser when a user would type in a URL and navigate to that location. The HTML that was sent back to the browser was pretty much human-readable, which meant anyone with little programming knowledge and a basic knowledge of command syntax could figure out what is going on in the page.

I can say this because I remember learning HTML code in those early days in a few days’ time. While I am not a programmer, I have written code in the distant past.

Those days (both me doing any code or parsing web pages) are so over now. Today’s web servers do a lot more than just transmit a bunch of HTML. They consolidate a great deal of information from a variety of sources: banners from ad networks, images from image headers that are used in visitor analytics, tracking cookies for eCommerce sites (so they can figure out if you have been there before), content distribution network codes and many more situations.

Quite frankly, if you look at all the work that a modern web server has to do, it is a wonder that any web page ends up looking as good as it does. But this note isn’t just about carping on this complexity. Instead, it is because of this complexity that the bad guys have been exploiting it for their own evil ways for many years, using what are called script injection techniques.

Basically what is happening is because of poorly written code on third-party websites or because of clever hacking techniques, you can inject malware into a web page that can do just about anything, including gathering usernames and passwords without the browser’s knowledge.

One type of injection, SQL injection, is usually near the top of the list of most frequent attacks year after year. This is because it is easy to do, it is easy to find targets, and it gets big results fast. It is also easy to fix if you can convince your database and web developers to work together.

But there is another type of injection that is more insidious. Imagine what might happen if an ad network server would be compromised so that it could target a small collection of users and insert a keylogger to capture their IDs and passwords. This could easily become a major data breach.

A variety of security tools have been invented to try to stop these injections from happening, including secure browsers (such as, using various sandboxing techniques (such as Checkpoint’s Sandblast), running automated code reviews (such as with runtime application self-protection techniques from Vasco and Veracode), or by installing a browser extension that can block specific page content. None of these is really satisfactory or a complete solution.

If you are concerned about these kinds of injections, you might want to experiment with a couple of  browser extensions. These are not new. Many of these tools were created years ago to stop pop-up ads from appearing on your screen. They have gotten new attention recently because many ad networks want to get around the ad blockers (so they can continue to make money selling ads). But you can use these tools to augment your browser security too. If you are interested in trying one of them out, here is a good test of a variety of ad blocker performance done several years ago. There is another comparative review by LifeHacker which is also several years old that focuses on privacy features.

I was interested so I have been running two of these extensions lately: Privacy Badger (shown here) and Ghostery. I wanted to see what kind of information they pick up and exactly how many third-parties are part of my web transactions when I do my banking, buy stuff online, and connect to the various websites that I use to run my life. The number will surprise you. Some sites have dozens of third-party sites contributing to their pages.

Privacy Badger is from the Electronic Frontier Foundation, and is focused on the consumer who is concerned about his or her online privacy. When you call it up onscreen, it will show you a list of the third-party sites and has a simple three-position slider bar next to each one: you can block the originating domain entirely, just block its cookies, or allow it access. Ghostery works a bit differently, and ironically (or unfortunately) wants you to register before it provides more detailed information about third party sites. It provides a short description of the ad network or tracking site that it has discovered from reading the page you are currently browsing. The two tools cite different sites in their reports.

There are some small signs of hope on the horizon. An Israeli startup called Source Defense is in beta; they will secure your website from malicious third-party script injections such as keylogger insertions. I saw a short demo of it and it seems promising. Browsers are getting better, with more control over pop-ups and third-party cookies and blocking more obvious malware attacks. Although as browser security controls become more thorough, they also become more difficult to use. It is the nature of the Internet that security will always chase complexity.

HPE Insights: 8 lessons about IoT security learned from the Mirai botnet

Botnets are a major threat, and require a combination of methods to defend against massive traffic volumes. Experts recommend a combination of steps to guard against attacks. You’ve probably seen your fill of Mirai-inspired headlines, but keep reading my article on HPE’s latest website. You’ll learn something essential to maintaining your overall IT security posture. I provide an overall timeline of events since last fall, show how Mirai was first detected, and what things you should do to protect your enterprise infrastructure. 

HPE Insights: 9 ways to make IoT devices more secure

Devices must be more secure if IoT is to reach its full potential. The good news is that security policies and procedures can protect enterprise infrastructure, harden IoT configurations, and make the network smarter and more defensible. Here is where to start, in an article that I recently wrote for a new HPE IT site, where I provide what the bottom-line impact will be for enterprise IT folks and digest information from various sources, including the latest reports from the Broadband Internet Technical Advisory Group (BITAG) and the Cloud Security Alliance.

The view from Joshua Belk, former FBI CSO

Joshua Belk is the co-founder of the security startup Opsec360. Previously, he was the cybersecurity manager at the electric utility PG&E and the CSO for the FBI back at the beginning of this decade.

His earliest memory of a security issue was with managing people: “I have found that no matter how comprehensive our policies may be, if you don’t have the right culture among your workforce they won’t matter. Education, understanding, and inclusion are the ways to build the right security environment.”

He is drawn to tools that provide useful analytics. “With TB of data available to your team, trying to find the needle in the haystack can be a challenge. Each tool has its place in your security architecture so picking one is difficult, but those which are capable of providing me good information for analysis are the ones I prefer. That said, knowing your use cases and setting up your tools is probably the biggest impact to any security organization.”

His best advice for dealing with insider threats is to first, start with the basics. “Many companies have not taken adequate measures to protect their information or environments. At the lowest level, access provisioning, data classification, and updated antivirus and firewalls are all mandatory but when new systems or services get introduced into your environment the effects are often not well known. Protect against the drift.”

He sees MDM as a careful balance between protecting the employee and preventing unauthorized access. “At the core of the issue, no one wants their data put at risk and most users and organizations are willing to conform to a good policy in order to protect themselves.”


Like what you are reading?

Subscribe to Inside Security! Tracking the Digital Transition in the White House

As President Donald Trump arrives at the White House to start his term, he faces a very different collection of technology than when former President Barack Obama entered eight years ago. Back then, government PCs sported floppy drives and no president ever personally used Twitter or other form of social media. But the task of making the digital transition isn’t easy, and I describe some of the electronic methods that are being used to preserve the Obama legacy. You can read my post on IBM’s blog here.

The legacy of the insecure IoT: HP’s JetDirect

If you are looking to trace the origins of an insecure IoT, you might want to take a walk down memory lane back to October 1991. Back then HP developed the first network printer server called JetDirect. This took the form of an internal circuit card shown here that came in both Token Ring (remember those?) and Ethernet versions that fit inside the early monochrome laser printers. I believe those early printers cost around $2400, so there was some cost motivation to share them around the LAN. HP had been selling the first desktop laser printers for several years and this was the first time that any of them could be easily connected to a network. During the 1990s there were several versions of JetDirect cards created, including external print servers that could connect to any printer that had a parallel port. It wasn’t long before they were commonly used, not just for printing but numerous other hacking activities.

Why is this the origin story of the insecure IoT? Check out this post on SecurityFocus from May 2003. Way before ransomware was common, the post describes a major vulnerability in the JetDirect web-based admin utility. Some network admins knew when they first got these devices that they could be configured via two different protocols: web and telnet. The post shows that the telnet interface didn’t have any default password, and if you had to reset the device, you would return to this default setting. Thus began the insecure IoT. At the time, there was a lot of discussion about printer insecurity, not just about HP but any network-connected printer: check out this SANS white paper from 2003.

When we look at this material with a modern eye, some of the hacks mentioned here seem, well quaint. But some are significant, such as having a hacker hosting malicious webpages and scripts on your printer, as mentioned in this recent article here. One of the attractions for using network printers is that usually no one looks carefully at their operations, either through activity logs or intrusion systems. Another advantage is that they are always on and if they have issues get rebooted quickly so they can continue to serve print jobs.

Now we have millions of network-connected devices of all shapes and sizes, but still have sub-par programming where passwords, secure protocols and other practices are few and far between. Granted, laying all this at the feet of HP isn’t really fair: they didn’t anticipate how networks would be abused decades later. But it shows that hardware vendors often give security short shrift. Since those early days, HP hasn’t been just sitting around either: In 2015 they came out with ultra-secure printers that protect any BIOS tampering and have other controls such as built-in intrusion detection.

It is nice to see that the JetDirect product, which started the insecure IoT, brought about some solid innovation in the modern era with better printer security. It has come full circle, to be sure.

Security Intelligence blog: Protecting your staff when in co-working spaces

The number of innovative co-working spaces continues to rise around the world, and this doesn’t even include coffee shops, libraries and numerous other public places that offer free Wi-Fi. It’s important to consider the security implications of what these itinerant workers are doing. IT managers are challenged to keep their networks and data secure while encouraging remote workers to be productive, whether they’re dialing in from the local WeWork or reviewing emails at McDonald’s.

Here are some practical security considerations from my latest blog post for IBM’s SecurityIntelligence. 

Did the Russians hack our election?

I have watched the series of reports about the Russians trying to influence our election last fall with a mixture of disbelief and interest. I wanted to put together links to some of the better reporting, and also call out some of the sub-standard reporting to steer clear from.

Let’s start with what we know and what has been released to the general public. The best quality of information came from this report from Crowdstrike back in June. They were called in by the DNC to try to get to the bottom of the attacks on their network. This post has many details that point out indicators that two separate Russian state intelligence agencies had penetrated their networks over a long period of time. They entered via phished emails and then proceed to infect various PCs with a boatload of malware, most of which was very clever at avoiding detection. When you look at the Crowdstrike report, you can see why this malware was so difficult to pin down: you needed the experience and context of other attacks by these Russian state actors to see the similar patterns of compromise.

I assume that our government has this experience, but getting them to tell civilians in an unclassified report is another matter entirely. Still such a report was done by the FBI and Homeland Security recently, and it can be found here. Sadly, this report comes up lacking in several areas: it doesn’t tie any specific Russian sources to these attacks, it doesn’t help network defenders to prepare their own networks for future similar attacks, and it contains mostly high-level platitudes and security chestnuts that aren’t very unique or actionable.

The feds didn’t do themselves any favors here. I agree with Bruce Schneier’s assessment: “If the government is going to take public action against a cyberattack, it needs to make its evidence public. It’s one thing for the government to know who attacked it. It’s quite another for it to convince the public who attacked it.” He links to previous attacks such as Sony, OPM, and Estonia that took some effort to figure out the originating offenders.

Also not helping matters was when the Washington Post ran a story about the Russians hacking into a Vermont electric utility. They later corrected the piece, leading with the statement they “incorrectly said that Russian hackers had penetrated the U.S. electric grid. Authorities say there is no indication of that so far.” Oops. The issue is that yes, one piece of malware, which can be purchased online from a variety of sources, was found on a laptop belonging to one employee of Burlington Electric. This laptop was a personal machine and not part of any operational function for the utility. The Intercept unpacks the Post story technically bit-by-bit so you can see the sloppy reporting and reactions forthwith.

Various security researchers have come out with similar negative reactions to the DHS/FBI report and the Post piece. Here are links to three of them:

So if you are a corporate IT manager, what needs to happen, going forward? First, you should re-read the Crowdstrike blog post from last June and make sure you – and your security staff — understand the various infection vectors used by the Russians. Next, you should take the time to ensure that your defenses actually will work against these vectors, and if not, what gear you need to put in place to make things more secure. Finally, you should not over-react to the general press stories about hacking attempts, without doing some careful investigation first. As a recent example, stories such as the US Customs computers going offline on Dec. 28th – which were originally attributed to a hacking attempt – turn out to be nothing more than a bad systems upgrade by their IT department.