Posts in Secure IT Practices
Page Content
What did you really expect?
[tags]reformed hackers[/tags]
A news story that hit the wires last week was that someone with a history of breaking into systems, who had “reformed” and acted as a security consultant, was arrested for new criminal behavior. The press and blogosphere seemed to treat this as surprising. They shouldn't have.
I have been speaking and writing for nearly two decades on this general issue, as have others (William Hugh Murray, a pioneer and thought leader in security, is one who comes to mind). Firms that hire “reformed” hackers to audit or guard their systems are not acting prudently any more than if they hired a “reformed” pedophile to babysit their kids. First of all, the ability to hack into a system involves a skill set that is not identical to that required to design a secure system or to perform an audit. Considering how weak many systems are, and how many attack tools are available, “hackers” have not necessarily been particularly skilled. (The same is true of “experts” who discover attacks and weaknesses in existing systems and then publish exploits, by the way -- that behavior does not establish the bona fides for real expertise. If anything, it establishes a disregard for the community it endangers.)
More importantly, people who demonstrate a questionable level of trustworthiness and judgement at any point by committing criminal acts present a risk later on. Certainly it is possible that they will learn the error of their ways and reform. However, it is also the case that they may slip later and revert to their old ways. Putting some of them in situations of trust with access to items of value is almost certainly too much temptation. This has been established time and again in studies of criminals of all types, especially those who commit fraud. So, why would a prudent manager take a risk when better alternatives are available?
Even worse, circulating stories of criminals who end up as highly-paid consultants are counterproductive, even if they are rarely true. That is the kind of story that may tempt some without strong ethics to commit crimes as a shortcut to fame and riches. Additionally, it is insulting to the individuals who work hard, study intently, and maintain a high standard of conduct in their careers -- hiring criminals basically states that the honest, hardworking real experts are fools. Is that the message we really want to put forward?
Luckily, most responsible managers now understand, even if the press and general public don't, that criminals are simply that -- criminals. They may have served their sentences, which now makes them former criminals...but not innocent. Pursuing criminal activity is not -- and should not be -- a job qualification or career path in civilized society. There are many, many historical examples we can turn to for examples, including those of hiring pirates as privateers and train robbers as train guards. Some took the opportunity to go straight, but the instances of those who abused trust and made off with what they were protecting illustrate that it is a big risk to take. It also is something we have learned to avoid. We are long past the point where those of us in computing should get with the program.
So, what of the argument that there aren't enough real experts, or they cost too much to hire? Well, what is their real value? If society wants highly-trained and trustworthy people to work in security, then society needs to devote more resources to support the development of curriculum and professional standards. And it needs to provide reasonable salaries to those people, both to encourage and reward their behavior and expertise. We're seeing more of that now than a dozen years ago, but it is still the case that too many managers (and government officials) want security on the cheap, and then act surprised when they get hacked. I suppose they also buy their Rolex and Breitling watches for $50 from some guy in a parking lot and then act surprised and violated when the watch stops a week later. What were they really expecting?
Fun with Internet Video
[tags]network crime, internet video, extortion, streaming video[/tags]
Here's an interesting story about what people can do if they gain access to streaming video at a poorly-protected site. If someone on the other end of the phone is really convincing, what could she get the victims to do?
FBI: Strip Or Get Bombed Threat Spreads - Local News Story - KPHO Phoenix:
Items In the news
[tags]news, cell phones, reports, security vulnerabilities, hacking, computer crime, research priorities, forensics, wiretaps[/tags]
The Greek Cell Phone Incident
A great story involving computers and software, even though the main hack was against cell phones:
IEEE Spectrum: The Athens Affair. From this we can learn all sorts of lessons about how to conduct a forensic investigation, retention of logs, wiretapping of phones, and more.
Now, imagine VoIP and 802.11 networking and vulnerabilities in routers and.... -- the possibilities get even more interesting. I suspect that there's a lot more eavesdropping going on than most of us imagine, and certainly more than we discover.
NRC Report Released
Last week, the National Research Council announced the release of a new report: Towards a Safer and More Secure Cyberspace. The report is notable in a number of ways, and should be read carefully by anyone interested in cyber security. I think the authors did a great job with the material, and they listened to input from many sources.
There are 2 items I specifically wish to note:
- I really dislike the “Cyber Security Bill of Rights” listed in the report. It isn't that I dislike the goals they represent -- those are great. The problem is that I dislike the “bill of rights” notion attached to them. After all, who says they are “rights”? By what provenance are they granted? And to what extremes do we do to enforce them? I believe the goals are sound, and we should definitely work towards them, but let's not call them “rights.”
- Check out Appendix B. Note all the other studies that have been done in recent years pointing out that we are in for greater and greater problems unless we start making some changes. I've been involved with several of those efforts as an author -- including the PITAC report, the Infosec Research Council Hard Problems list, and the CRA Grand Challenges. Maybe the fact that I had no hand in authoring this report means it will be taken seriously, unlike all the rest. :-) More to the point, people who put off the pain and expense of trying to fix things because “Nothing really terrible has happened yet” do not understand history, human nature, or the increasing drag on the economy and privacy from current problems. The trends are fairly clear in this report: things are not getting better.
Evolution of Computer Crime
Speaking of my alleged expertise at augury, I noted something in the news recently that confirmed a prediction I made nearly 8 years ago at a couple of invited talks: that online criminals would begin to compete for “turf.” The evolution of online crime is such that the “neighborhood” where criminals operate overlaps with others. If you want the exclusive racket on phishing, DDOS extortion, and other such criminal behavior, you need to eliminate (or absorb) the competition in your neighborhood. But what does that imply when your “turf” is the world-wide Internet?
The next step is seeing some of this spill over into the physical world. Some of the criminal element online is backed up by more traditional organized crime in “meat space.” They will have no compunction about threatening -- or disabling -- the competition if they locate them in the real world. And they may well do that because they also have developed sources inside law enforcement agencies and they have financial resources at their disposal. I haven't seen this reported in the news (yet), but I imagine it happening within the next 2-3 years.
Of course, 8 years ago, most of my audiences didn't believe that we'd see significant crime on the net -- they didn't see the possibility. They were more worried about casual hacking and virus writing. As I said above, however, one only needs to study human nature and history, and the inevitability of some things becomes clear, even if the mechanisms aren't yet apparent.
The Irony Department
GAO reported a little over a week ago that DHS had over 800 attacks on their computers in two years. I note that the report is of detected attacks. I had one top person in DC (who will remain nameless) refer to DHS as “A train wreck crossed with a nightmare, run by inexperienced political hacks” when referring to things like TSA, the DHS cyber operations, and other notable problems. For years I (and many others) have been telling people in government that they need to set an example for the rest of the country when it comes to cyber security. It seems they've been listening, and we've been negligent. From now on, we need to stress that they need to set a good example.
[posted with ecto]
Diversity
[tags]diversity, complexity, monocultures[/tags]
In my last post, I wrote about the problems brought about by complexity. Clearly, one should not take the mantra of “simplification” too far, and end up with a situation where everything is uniform, simple, and (perhaps) inefficient. In particular, simplification shouldn't be taken to the point where diversity is sacrificed for simple uniformity.
Nature penalizes monocultures in biological systems. Monocultures are devastated by disease and predators because they have insufficient diversity to resist. The irish potato famine, the emerald ash borer, and the decimation of the Aztecs by smallpox are all examples of what happens when diversity is not present. Nature naturally promotes diversity to ensure a robust population.
We all practice diversity in our everyday lives. Diversity of motor vehicles, for instance supports fitness for purpose -- a Camero, is not useful for hauling dozens of large boxes of materials. For that, we use a truck. However, for one person to get from point A to point B in an economical fashion, a truck is not the best choice. It might be cheaper and require less training to use the same vehicle for everything, but there are advantages to diversity. Or tableware -- we have (perhaps) too many forks and spoon types in a formal placesetting, but try eating soup with a fork and you discover that some differentiation is useful!
In computing, competition has resulted in advances in hardware and software design. Choice among products has kept different approaches moving forward. Competition for research awards from DARPA and NSF has encouraged deeper thought and more focused proposals (and resultant development). Diversity in operating systems and programming languages brought many advancements in the era 1950-2000. However, expenses and attempts to cut staff have led to widespread homogenization of OS, applications, and languages over approximately the last decade.
Despite the many clear benefits of promoting diversity, too many organizations have adopted practices that prevent diversity of software and computing platforms. For example, the OMB/DoD Common Desktop initiative is one example where the government is steering personnel towards a monoculture that is more maintainable day-to-day, but which is probably more vulnerable to zero-day attacks and malware.
Disadvantages of homogeneity:
- greater susceptibility to zero-day vulnerabilities and attacks
- “box canyon” effect of being locked into a vendor for future releases
- reduced competition to improve quality
- reduced competition to reduce price and/or improve services
- reduced number of algorithms and approaches that may be explored
- reduced fitness for particular tasks
- simpler for adversaries to map and understand networks and computer use
- increased likelihood that users will install unauthorized software/hardware from outside sources
Advantages of homogeneity:
- larger volume for purchases
- only one form of tool, training, etc needed for support
- better chance of compatible upgrade path
- interchangeability of users and admins
- more opportunities for reuse of systems
Disadvantages of heterogeneity:
- more complexity so possibly more vulnerabilities
- may not be as interoperable
- may require more training to administer
- may not be reusable to the same extent as homogeneous systems
Advantages of heterogeneity:
- when at a sufficient level greater resistance to malware
- highly unlikely that all systems will be vulnerable to a single new attack
- increased competition among vendors to improve price, quality and performance
- greater choice of algorithms and tools for particular tasks
- more emphasis on standards for interoperability
- greater likelihood of customization and optimization for particular tasking
- greater capability for replacement systems if a vendor discontinues a product or support
Reviewing the above lists makes clear that entities concerned with self-continuation and operation will promote diversity, despite some extra expense and effort. The potential disadvantages of diversity are all things that can be countered with planning or budget. The downsides of monocultures, however, cannot be so easily addressed.
Dan Geer wrote an interesting article for Queue Magazine about diversity, recently. It is worth a read.
The simplified conclusion: diversity is good to have.
Optional Client-Side Input Validation That Matches Server-side Validation
def initialize(...)
(...)
@regexp = Regexp.new(/^\d+$/) # positive integer
end
This regular expression can be used to perform the initial server-side input validation:
def validate(input)
if input == nil
unescaped = default()
else
unescaped = CGI.unescapeHTML(input.to_s.strip)
end
unescaped.scan(@regexp) { |match|
return @value = match.untaint
}
if input != ''
raise 'Input "' + @ui_name + '" is not valid'
end
end
To perform client-side input validation, the onblur event is used to trigger validation when focus is lost. The idea is to make the input red and bold (for color-blind people) when validation fails, and green when it passes. The onfocus event is used to restore the input to a neutral state while editing (this is the Ruby code that generates the form html):
def form
$cgi.input('NAME'=>@name, 'VALUE'=>to_html(), 'onblur' => onblur(),
'onfocus' => onfocus())
end
def onblur()
return "if (this.value.search(/" + @regexp.source + "/) < 0)
{this.className = 'bad'} else {this.className = 'good'};"
end
def onfocus()
return "this.className = 'normal';"
end
where the classes "bad", "good" and "normal" are specified in a style sheet (CSS).
There are cases when more validation may happen later on the server side, e.g., if an integer must match an existing key in a database that the user may be allowed to reference. Could the extra validation create a mismatch? Perhaps. However, in these cases the client-side interface should probably be a pre-screened list and not a free-form input, so the client would have to be malicious to fail server-side validation. It is also possible to add range (for numbers) and size (for strings) constraints in the "onblur" JavaScript. In the case of a password field, the JavaScript contains several checks matching the rules on the server side. So, a lone regular expression may not be sufficient for complete input validation, but it is a good starting point.
Note that the form still works even if JavaScript is disabled! As you can see, it is easy to perform client-side validation without forcing everyone to turn on JavaScript ;)


