Bill’s Security Blog

Computer World Security reprinted a 2003 CIO.com article entitled: 2010: The Future of Security.

While I don’t like articles/news that engage in fear mongering, this article does lay out some likely outcomes of the growing perception of insecurity in computer system.

I say “growing perception” not to say that things are all fine and dandy in the security arena, but to indicate that the average Joe, and Joe’s elected official, are starting to notice.

Two things I’d like to address.

First, the article cites some work and quotes from perhaps one of my favorite software engineers, Watts Humphrey:

 We’re letting creative artists build bridges, he says, then trying to stabilize them with unlicensed laborers while they’re collapsing.

“I want the technical community to become professionals,” Humphrey says, “to say, This is how we do our job.”

TSP and PSP have already been found to reduce coding errors by factors of up to 10 or more. Microsoft tried it and reduced bugs within a 24,000-line program from more than 350 to about 25.

Humphrey also has conceived of even more radical changes, including a software engineering curriculum modeled on medical school, complete with professional internships.

Now, I’m not bashing Microsoft here, I’m trying to make a point.  Microsoft engaged in the endeavor to increase their security and reliability because of customer demand.  People got sick and friggin tired of the crap they were being fed for huge cost.

A big driver of this frustration was the infamous BSOD.  The blue screen of death put a tangible face to the problem.

The insecurity inherent in our digital world is mostly faceless.  This fact, in my opinion, will make it harder to get wide-scale changes to happen.

If we want to eradicate the enemy of insecurity, we have to put a face on it…

Second, the article describes how we go from “free and open” to a “police state” very well.  Summarizing:

1. The first response is litigation.
2. After litigation comes regulation.
3. “What follows regulation?” asks Jeff Schmidt. “Standards.”
4. The final phase of the corrective response to the digital Pearl Harbor will be a reformation, a cultural shift toward better, more proactive security.

But the article fails in taking this picture to it’s logical end.

I don’t believe 3 and 4 will happen.  What will happen is “governmental oversight” stemming from regulations.

Lets look at the track record of, say, the TSA.  Are we prepared to have an organization like that managing our country’s networks and infrastructure?

Likely, however, we’ll end up there.  The sad truth is, that TSA has done little to improve transportation security, and future governmental organizations will do just as ineffectively.

But the general public can SEE the TSA, and though they hate it, are somehow drinking the cool-aid and believing that things Must be more secure.

The result - why do something else?  “The TSA is there, we’re safe, aren’t we?”

In my mind, that’s the end fallacy of governmental regulation.  It:

• gives a false sense of security
• puts organizations in the position where they’ll do the bare minimum to comply.

I do believe that government can do things to change how this whole security thing shakes out, but their track record is very bad.

The best thing the government can do, in my opinion, is demand security, built-in, from the bottom-up, in everything they do.  Every contract they develop, every system they buy, every contractor they hire.

The government’s initiative in this arena would give vendors the financial incentive they need to build security into the process.

The effect is that everyone benefits.

Bill

While most of the vulnerability alerts I see are XSS and SQL injection, there are some really nasty low level attacks coming out.

I’ve posted about Blue Pill  and subverting virtual infrastructures.

Kris Kaspersky of Kaspersky Labs has uncovered flaws in certain Intel chips that can allow remote attackers to execute arbitrary instructions. (Read: Remote code execution through Intel CPU bugs)

Now, let’s think about this a sec.  The flaw is in the CPU, not the OS.

It doesn’t matter what OS, how hardened it is, or nuthin’.

If you can get your attack instructions to the CPU, the processor will happily run them.

Pwnage at the lowest level.

Intel has reportedly fixed the remotely exploitable bugs (it will not fix the non-remotely exploited bugs):
Researcher: Intel fixed two critical flaws in its chips
Intel proactively fixes security flaws in its chips

But what does a processor patch look like?  Can you say firmware update?

That’s my speculation.

How many people are going to run out and patch their CPU firmware?

I don’t think there is an “automatic update” for my CPU… lol.

In any event, it will be interesting to watch this story.

Bill

Definitions

What is Attack Surface?

Imagine you and a few friends are in a snowball fight.

Let’s say target number 1 is 4′9” tall and weighs 75 lbs.

Lets say target number 2 is 6′2” tall and weighs 290 lbs.

Now you start throwing snowballs.

Who are you more likely to hit, Skinny Bob, or Big-A$$ Charlie?

In the Infosec space, we refer to this as Attack Surface.

We measure size by quantifying the number of installed software or services available in an information system.

Mitigation

Say Big-A$$ Charlie hates getting hit by snowballs.

Now, unless he get some major plastic surgery and possibly significant amputations, he’s still going to be a pretty easy target.

But in the IT space things are a little different.

We have the ability to decrease the attack surface with little loss in capability.

Rant

So why don’t we?

Convenience.

Bruce Schneier in his book with Niels Ferguson, “Practical Cryptography” state:

“There are no complex systems that are secure.  Complexity is the worst enemy of security, and it almost always comes in the form of features or options.”

We need to quit thinking about security as something we can address whenever we get an IDS alert.

Security should be pervasive.

It must influence decisions from the start of a project.

When we do a project, we look at cost-benefit.

Security issues can pose significant costs.  Ask any company with a large data breach…

It’s time to quit acting like a bunch of little sissies and start taking this stuff seriously.

I can assure you, motivated and financially backed attackers are…

Bill

ControlGlobal recently posted an article, “Advances Needed in Control System Cyber Security” discussing the Control System Security Program (CSSP).

Quoting:

CSSP has produced some significant risk reduction products, including a cyber security self-assessment tool, a detailed cyber security procurement language for control systems, a pocket guide to securing SCADA and control systems, and a set of recommended practices. CSSP has also set up a group within US-CERT to produce control-systems- related vulnerability notices, and CSSP teaches control systems security awareness and mitigation training classes. All of this information is available at http://www.US-CERT.gov/control_systems.

One of the most important initiatives CSSP has undertaken, Hoffman revealed, is the technology assessments they do under contract, and with nondisclosure agreements, for control systems vendors. “Basically, we get the hardware and the control systems engineers from the vendor, and we build a system and get it ready. Then our “Red Team”—that’s the attackers—get six weeks to invade and take control of the system.

“In four years of doing this,” Hoffman said, “we have never been stopped from gaining full operational control over the control systems.”

Now that’s what I’m talking about.

If industry can engage this kind of effort, I think they will be able to avoid ugly regulatory requirements that, IMHO, will generally be reactionary and low value.

From the looks of the CSSP, they are doing some really good things in control system security from a standards development and best-practices establishment perspective.

I’m an IT security guy, not a control systems security guy.

I hear a lot of complaining from the control system side that the IT guys don’t understand the complexities of control systems.

I’ll agree that there’s a lot I don’t know about control systems, but I also believe there’s a lot that the control system community doesn’t know about IT security.

But we can both learn from each other.

One aspect I think the IT security can bring is that, in general, IT security systems are constantly under attack, and we’ve had to embrace certain principles in order to achieve a degree of success.

Good IT security embodies the principles of:

• Secure by design
• Secure by default
• Defense in depth
• Constant monitoring and improvement the security posture

Though the same “technical security controls” I use in a corporate network may not work in the control system space, the fundamental principles can drive a good security practice.

Bill

This from Shaun Davies on ninemsn:

A cyberspace battle is running in parallel to the war in Southern Ossetia, as hackers launch sustained attacks on the Georgian government.

Websites for Georgia’s president and parliament have been knocked offline and even defaced in the attacks, which commenced almost two weeks ago and intensified when the fighting between Georgia and Russia began.

Perhaps it’s all botnets and DDOS between Georgia and Russia, but you better believe that confrontations between nation states will extend well beyond the battle field.

The nice thing about conventional warfare (if there are any nice things…) is that you can see the damage, it is tangible.

In cyber warfare:
You may not be able to see physical damage
You may not be able to see or identify the perpetrators
Damage may not be noticed until long after it’s been done
You may not be able to determine if damage has been done
The list goes on

I hope NSA and CIA are better than the adversary…

Bill

A brief, somewhat-weekly post for non-security people who want to know what’s going on in the security space.

Black Hat / Defcon
Lots of goodness coming out of Las Vegas.

I. Owning the Virtual Infrastructure
Joanna Rutkowska and Rafal Wojtczuk of Invisible Things Labs gave a series of talks about owning virtual infrastructures.

Joanna builds on techniques she used in the Blue Pill Project to install a root kit on a running machine with zero user assistance.  The root kit essentially virtualizes the host OS, sliding the Blue Pill between the hardware and the host OS.  Scary stuff.

Please, for the love of god and all that is holy, don’t assume that since you went virtual, that you were safe.

If you can own the hypervisor, you can own the hardware, and all the virtual machines.

Joanna and Rafal show how to do it.  Though they talk about Xen, assume their research applies to any virtualization platform.

Good stuff.

Posts with more details:
Owning Xen in Vegas!
Our Xen 0wning Trilogy Highlights
Presentations

II. GIFAR
Combining a GIF image and Java JAR applet into a single attack package.

Rich Mogul of Securosis explains best in his blog post, “The Risks of Trusting Content:”

GIFs (and most image file formats) include their header information (the part that helps your system know how to render them) at the beginning of the file, and JARs (java applets, really ZIP files) include their header information at the end. A GIFAR is simultaneously a valid GIF and a valid JAR (albeit with extra bits), meaning that when the file is loaded, it will look like an image (because it is), but as it’s rendered at the end it will run as an applet. Thus you think you’re looking at a pretty picture, since you are, but you’re also running an application.

Note, the application is running in the context of the logged in user, and in the security domain of the website serving the picture.

What happens if one of these is uploaded to your bank’s website?

No reports of this in the wild, but neat stuff.

I’ll likely have more next week, after I get through all the material coming out of Vegas.

New Tools
Karmetasploit

A combination of two awesome tools, Karma and Metasploit.

Karma is a wireless penetration testing tool, and Metasploit is a  penetration testing tool that automates exploit payload delivery.

Together these two tools can do tremendous things.

The basics are, you set up a laptop running Karmetasploit.  Then, let the owning begin.  The box can act like any requested access point, and all traffic will be routed through the laptop…  All your bits are belong to us!

Here’s a quick list of fun things you can do with Karmetasploit from Metasploit creator HD Moore on the Metasploit blog:

• Capture POP3 and IMAP4 passwords (clear-text and SSL)
• Accept outbound email sent over SMTP
• Parse out FTP and HTTP login information
• Steal cookies from large lists of popular web sites
• Steal saved form fields from the same web sites
• Use SMB relay attacks to load the Meterpreter payload
• Automatically exploit a wide range of browser flaws

That’s it for now.

Bill

Joe Weiss is a big fan of strong regulation to help improve critical infrastructure security in the US.

I agree that sweeping regulation can be a benefit in certain situations.  For example:

1. When there’s a need to make a large cultural shift
2. When there’s a need for consistency across a sector
3. Safety reasons

Now, I’m not as plugged in as Weiss is, and I’m not sure the scope of the NERC CIP’s or the history of regulatory work coming out of NERC and FERC, but I do have a fundamental belief that Federal agencies do few thigs well.

I believe that good Federal regulation should be:

• Performance based
• Easily verified
• Consistent

Regulation must be performance based, rather than solution specific.

As Joe pointed out, a checklist isn’t going to motivate a significant change.  The result will be to do only what is necessary to meet the items on the checklist.

If consistently improving security is what is desired, then the basis of the regulation must be performance based.

As an example, “the control network should not be impacted by events on the business network.”

Regulation should not be created in a moment of panic.  We all see the kinds of things that come out of panic… Think, TSA :(

Regulation should also be verifiable.

There must be a consistent way to measure compliance with a regulation.

For example, “compliance can be verified by ensuring the control network can withstand a targeted attack by a knowledgeable adversary.”

Regulation should be consistent.

There are two branches here.  Obviously, regulations should not create a situation where compliance with one places you out of compliance with another.

But more importantly, regulations should be consistent across sectors.

For example, there should be a set of regulations that cover power production or the energy sector at large.

Though there is institutional reasons why this would be hard to achieve (think NERC v NRC), there are substantial benefits to having a consistent set of regulation.

There are many power producers that own both Nuclear and fossil based power facilities.

A consistent regulatory body gives them to optimize their processes, procedures, and project pipelines.

Each production type that has unique characteristics can be supported by additional regulation.

Bill

This past week I was listening to the Digital Bond podcast for July, 2008.

One of the topics was whether or not the Hatch Nuclear Power Plant incident constitutes a cyber security incident.

About the Hatch incident:

The computer in question was used to monitor chemical and diagnostic data from one of the facility’s primary control systems, and the software update was designed to synchronize data on both systems. According to a report filed with the Nuclear Regulatory Commission, when the updated computer rebooted, it reset the data on the control system, causing safety systems to errantly interpret the lack of data as a drop in water reservoirs that cool the plant’s radioactive nuclear fuel rods. As a result, automated safety systems at the plant triggered a shutdown.

Southern Company spokeswoman Carrie Phillips said the nuclear plant’s emergency systems performed as designed, and that at no time did the malfunction endanger the security or safety of the nuclear facility.

Phillips explained that company technicians were aware that there was full two-way communication between certain computers on the plant’s corporate and control networks. But she said the engineer who installed the update was not aware that that the software was designed to synchronize data between machines on both networks, or that a reboot in the business system computer would force a similar reset in the control system machine.

Washington Post.com

The guests on the podcast seemed to be making sometimes contradictory arguments of why the incident was not a cyber security incident.

Arguments included whether or not participant had malicious intent, or whether or not any ‘real’ damage was caused.

I suspect that if you are in a regulated space where an event that is considered “cyber security” carries significant regulatory implication, then you would be motivated to call an event anything but a cyber security event.

But lets back up a second.

Information security seeks to ensure the confidentiality, availability, and integrity of information.

If an event affects either of those three, then it is a breach of information security.

If, when we refer to cyber security, we are really talking about digital information and information system security, does that somehow preclude the provision of confidentiality, availability, or integrity?

I think not.

Indeed, I think a proper definition of cyber security is the assurance of confidentiality, availability, and integrity of digital information and information systems.

The Hatch incident was a cyber security event by definition.

Let’s not try to confuse this stuff, it’s already hard enough.

Bill

Background

The information security field is maturing.

But there are still challenges.

The information security field has not matured to the level of other broad reaching institutions.

One particular area of concern for me is in how the industry deals with events that cut across the entirety of the infosec space.

How does the US Centers for Disease Control (CDC) handle, or prepare to handle, large-scale outbreaks?

How does a country like Japan, for example, mature their processes to the point where they can train millions of people how to properly prepare for, and execute an evacuation of an entire city in the event of an earthquake or Tsunami?

The events surrounding the recent DNS issue further exemplifies and illustrates the weaknesses in the security space’s abilities to handle large scale critical security incidents.

My fiance is in the public health field and works closely with US Centers for Disease Control (CDC) on the topic of food safety.  They recently dealt with a nation-wide samonila outbreak.  I was fortunate to learn a little about how they deal with these events.

Throughout this post, I’ll refer to what I’ve learned about how CDC is able to coordinate disparate groups to accomplish a common objective.

Overview

Off-the-cuff, I came up with a list of the primary phases of large-scale incident handling.  I tried to think beyond just the infosec space…

The phases I’ll discuss are:
Discovery
Analysis
Vetting
Damage Control
Recovery and Response
Post-Incident Analysis and Process Enhancement

I’ll discuss what goes into each phase and refer to how the DNS incident highlights where we need to improve.

I’ll end with some remarks and a vision of what I’d like to see happen.

Objective

The objective of this post is to raise the level of discourse beyond the DNS incident, and focus on the future.  I want to leverage this incident to take a step forward.

I’ll refer often to how the DNS incident was handled, but the reader should try to avoid interpreting judgement on my part.  I’m not trying to debate how person X did Y, or should A have done B.  I make references to events only to illustrate how we can learn and improve.

I want the reader to walk away thinking about how we can do better…

Discovery

This one is a bit of a no brainer.  This is where an issue is identified.

It can come up as the part of a risk assessment, a vulnerability assessment, incident response, or read on a blog post.

Humorously, in this case, Dan’s discovery was, as he admits, quite by accident.

In the infosec space, we can classify the discoverers into two broad classes:

• Bad guys - for example, those with a vested financial interest in exploiting the vulnerability without the consent of legitimate users.
• Good guys - for example, vulnerability researchers or incident handlers discovering where the bad guys are one step ahead.

Like the security sector, CDC has to deal with threats introduced by good guys and bad guys.

We also both have good guys with a vested interest in “getting to the fix first.”

Now, I’m not trying to claim that the CDC is perfect, but they have something we lack.  Coordinated discourse at the national level respecting incident handling.

Discovery, for them, may involve a little of the, “OMG!  Did you read about…”  But they also take a very proactive approach.

CDC works aggressively with hospitals and institutions to correlate “event data” to determine if there is an outbreak.

This high level of interaction builds collaboration, enhances communication, and keeps all levels aware of the significance of what they are doing.  CDC deals with serous stuff.  And the DNS vulnerability is the equivalent of a cyber bird-flu.

In our space, there is no focused point of aggregation of vulnerability information.  We have public (federal agencies), private, and underground channels.  Can we do better?

Using the Risk = Vulnerability * Threat * Consequence equation, discovery results in the identification of a vulnerability.

Analysis

Analysis involves considering the impact of the vulnerability identified in the discovery phase.  What’s the threat?

Dan, after doing more research on what he found, pulled together a team of industry insiders, experts, leaders.

I suspect the conversation was a bit like, “I think what I found is huge, here’s the details, what do you think?”

This conversation undermines the entire process if the people in that room can’t be trusted.

At this point, trust enters the equation.

As I discussed earlier, CDC can pull together public officials, industry leaders, and other key players.  One of CDC’s big concerns is pannic.  For example, it has to consider that if it says “tomatoes have been identified as the source” that there may be farmers that may loose everything as the result of the disclosure and resulting demand reduction for tomatoes.  Trust must exist.  CDC must trust that people receiving information will handle it properly, responsibly.

In Dan’s case, he was able to pull such a team together.

Though we are starting to develop this capacity as an industry, we definitely need to focus some attention here.

Vetting

Once consensus is reached that the vulnerability carries a reasonable level of threat, vetting allows us to determine consequence.

At this point, additional research might need to be done.

In the DNS case, I’m sure there was consideration of how quickly a remedy could be introduced, how long it would take to formulate a hack once the vulnerability hit the public, and what the consequence would be in the time between exploit and remediation.

In this case, I think the CDC has it a little easy.  Historical information can help inform the risk to humans.  Lost work, impact on the health infrastructure, potential for death can be analyzed from previous incidents.

In the Security space, we have a bit of a challenge here.

How do you calculate, at a national level, the consequence of the DNS vulnerability?  Every organization may have different consequences, and I don’t think there’s really any solid mechanism to statistically analyze cyber security costs at the level needed to inform the analysis.

This situation is further compounded by the lack of institutionalized communication channels.

As an industry we’ve historically struggled with senior management on budgetary issues because consequence is hard to calculate.

This is beginning to change somewhat, but we need to get to a point where we understand the costs to business, and can communicate clearly to representatives who are working at analysis.

In Dan’s case, from what I understand, there was pretty immediate acceptance that the consequence was very high.  It may not have needed to be calculated as a dollar figure, but consensus resulted in a good outcome.

We know have the pieces of information needed to determine the overall risk.

Damage Control

Cognizant of the risk, we can develop a reasonable mitigation strategy.

In the DNS case, it involved the coordinated effort of 16 key vendors develop, test, and prepare to deploy patches to over 60 DNS products.

In the CDC case, for example, this is the development of a vaccine.

Consensus must be reached on how the risk mitigation strategy will be implemented.  With the DNS vulnerability, the plan was to release patches and announcements simultaneously, and for Dan to do a full disclosure roughly 30 days later.

What Dan and his team did successfully was to come up with a good risk mitigation plan.

In the ideal world, it would have come off without a hitch.

But we’re still maturing, and the plan didn’t work out.

I’m not passing judgement, but I think that we can learn a great deal from how the risk mitigation played out.

So far, this is where I see most of the post-incident analysis focusing.  I’m reading a lot of how the disclosure and subsequent events ’should’ have been handled.  But We have to look broader…

What we need is an informed process on how to handle recovery and response, and the key players must be bought in.

Recovery and Response

Recovery and response is where we execute our risk mitigation strategy.

When the strategy is “patch”, the infosec space has vastly improved.

Almost all major OS and software vendors have implemented easy update processes that can often be automated.

There are cases where automatic updating is not advisable, and our risk mitigation strategies must consider this.

But a coordinated communication hierarchy can help improve information dissemination.  Our system administrator must know that “tonight is a stay late and patch” night.

When handling a virus outbreak, CDC would take this time to issue alerts to hospitals or other health facilities, and begin, if necessary, distribution of vaccines.  CDC, for the most part, has these communication channels nailed down.

In my opinion, this phase highlights the communication conundrum in the infosec space.  The DNS vulnerability, in my opinion, was a once-in-a-decade if not lifetime event.  How did this message get to Joe-Q system administrator?

We need to change and improve.

Post-Incident Analysis and Process Enhancement

At this point in the process, we can take a look at how we performed.

We have the opportunity to review and analyze our processes and procedures and see how we can do better next time.

In my opinion, the IT sector as a whole does a pretty bad job here.  Generally we are off to work on the next project.

I think this is a big mistake.

We need to focus attention here.

Conclusion

The recent DNS vulnerability and how it was handled gives the information security sector an excellent opportunity to take a look at how far we’ve come, and where we need to go.

We have smart people in this space.  Over the last 3 weeks I’ve read over a thousand blog posts, listened to over 10 podcasts, and done a lot of discussing with colleagues respecting this issue.

What I came away with was, “Damn, there are some smart people here!”  And I’m not talking just plain geek smartness.  I heard a lot of business savvy, a lot of common sense, and a lot of critical thinking and analysis.

But where can we do better?

The infosec space has some unique characteristics, but there is a lot we can learn from other, more mature, institutions.

We’ve come a long way, and we need to focus on how we develop industry-wide collaboration.  IR&R is a great opportunity for us to begin this process.

We should be looking at institutions that do this stuff regularly.  What do they do?  What can we take away?  Lets take a look outside the box.

This stuff may be rocket science to the infosec sector at the national or international level, but in other sectors they’ve already got men on the moon…

I’d like to take a minute to address the issue of those with a vested interest in early disclosure.  Penetration testing companies don’t need to be kicked to the curb here.  They can bring a lot to the discussion, and can benefit from being at the table at all phases too.

The issue is that responsibility must be to more than the bottom line.

Everyone should be engaged, and I don’t think we should shut anyone out.

We may need to find ways of addressing things like the buying and selling of vulnerabilities, but let’s have an informed discussion.

A vision

I think that a lot of discussion needs to happen, but I do have a vision for where I’d like to see us end up…

What would I like to see?

• A trusted tier-one group of multi-sector representatives that meet frequently, and have a good ability to determine consequence quickly.
• This group has accepted procedures for handling events through the remediation phase and perform post incident analysis.
• A group of mid-tier folks who know the seriousness of what’s coming out of group 1. and have have the tools, and resources needed to hit the ground running.
• This group interfaces regularly with the tier-one group on process analysis and improvement.
• I want to see a broadly known, easy mechanism for vulnerabilities to be introduced to the vetting cycle and be handled appropriately, and I want the process for doing this to be no-risk to the discloser.

I want the obscure, high-school kid who discovers a flaw in a critical system to have a place to go and have his concerns vetted.

I’d like to see the intelligence agencies come to the tier-one group and discuss an issue without the risk that sources might be compromised, or that the information would be mishandled.

At the moment, that’s a pipe-dream :/

The security industry has come a long way, but we have a long way to go.

Keep your eyes on the prize.

Bill

From last time…

Still a lot of aftermath from the DNS vulnerability.

This week at Black Hat / Defcon, Dan releases full details…  Over 100 slides.  Dan discusses some creative ways this vulnerability can be exploited.

A vid of his talk should be available somewhere soon.

Awesome video of infected DNS servers…  Look below the embedded video to see the HD version.

Malware

Much chatter about the changing threatscape of spammers.  A newish technique in bot creation is using enticing emails/web pages to get people to watch a video.

When the user click the video to start playing, the user is asked to install a player to be able to view the video.

If they install it… Well, you get the idea.

Attack Vectors

XSS, SQL Injection…

Well, beyond what I talked about above, mostly it seems that direct attacks using XSS and SQL Injection are the new low-hanging fruit.

Automated XSS and SQL Injection tools abound.

There’s even Firefox plug-ins that automates testing for XSS and Injection…

Social Network Pwnage

Lots of stories about worms traversing social networking sites.  Many using the tactic described in the Malware section above.

The threat here is that the post you see might appear to come from a friend… and hence have a higher trust.

You should not Trust anything on the Internet, especially on a social networking site.

Kaspersky Labs posted a good overview of the vector.

Automatic Updates
Some new info coming out about how most automatic update systems are flawed in that they don’t properly ‘authenticate’ the downloaded update, allowing pwnage.

Reading Room

I’m trying to stay on top of all the hotness coming out of Las Vegas this week.