Preventing scanning in paper

Check out “Document security processes”, US patent application 225,214. This details using a glossy mark technique wherein Xerox prints a glossy coat onto the paper. The coat prevents copying and scanning from the paper back to computers.

Inside the Twisted Mind of the Security Professional

“Security requires a particular mindset. Security professionals — at least the good ones — see the world differently. They can’t walk into a store without noticing how they might shoplift. They can’t use a computer without wondering about the security vulnerabilities. They can’t vote without trying to figure out how to vote twice. They just can’t help it.”

The ongoing criminalization of network attacks is one of the top security concerns we face today. The breaking and entering into computer networks has become a billion dollar global industry. Yesterday’s script kiddies are fast being replaced by organized gangs with the time and resources to carry out ever sophisticated attacks.

Yet there is a lag in the public’s awareness of this change, which is another security concern. It is taking quite a while for people to develop the Internet equivalent of street smarts. That goes for everyone, mind you, from the front desk receptionist to the back office network administrator. People still make decisions that put them at the mercy of online criminals.

Of course, the relative low quality of software only helps the criminals. There are plenty of vulnerabilities waiting to be exploited. Add to this that some security technology for sale is blatantly broken (like the secure hard drive this week that turned out to be encoded rather than encrypted, XOR rather than AES). All this serves to give the criminals plenty of opportunities to do what they do best.

Now this post paints a bleak picture, to be sure. But I see it as more of a call to arms. There are lots to be done in this field to get the Internet in order.

New Scientist has posted the article Friendly ‘worms’ could spread software fixes. Bruce Schneier has posted his thoughts. “Patching other people’s machines without annoying them is good; patching other people’s machines without their consent is not. A worm is not ‘bad’ or ‘good’ depending on its payload. Viral propagation mechanisms are inherently bad, and giving them beneficial payloads doesn’t make things better. A worm is no tool for any rational network administrator, regardless of intent.”

I agree that consent must be obtained before installing software. Yet this was one article in which I found myself disagreeing with Schneier. I get the impression that he, like so many others, are commenting without actually reading Milan Vojnovic’s work.

Does Vojnovic explicitly address permission? Not that I see. The focus is on rapid distribution. The key here is to build a system upon the mechanisms that worms use. Alright, so forget the sensitive term “worm”. Let us call this a distributed software delivery agent.

Such a distributed software delivery could be protected in many ways. A client side agent could provide a mechanism for the end-user to approve or deny the software package. The package itself could be code signed to mitigate tampering. Furthermore, in corporate environments, the package could come with a Kerberos ticket authorizing its distribution.

The last protection is an important one. It is not really the consent of the user that matters in corporate environments. It is the consent of the owner as delegated to the system administrator. The longer it takes the administrator, the greater the exposure is to the threat. It is difficult to patch organizations that are large, complex, subnetted, and have multiple sites. Using this distributed software delivery mechanism directly addresses these large vulnerable businesses.

Why not use a worm’s techniques to build a legitimate delivery mechanism?

Last week, I sat down to a project meeting. The project is implementing Sharepoint 2007. As I looked over the sprawling Gantt chart, one thing immediately struck my attention. No security tasks!

The first objective in securing web access is to get security integrated into the deployment project plan. The second objective is to get regular security reviews integrated into the change management process. That way, you can be reasonably assured that the system goes in secure and stays secure.

As a bonus, this approach means that security is not a roadblock but just another task. Often system owners and engineering want to avoid security review over concerns that it slows down the implementation. This can be avoided by baking it into the project. After all, a few hours pales when listed next to the hours the implementation team are spending. In this particular case, the InfoSec tasks are 48 hours out of 400, or 12%.

What am I doing with this time? First, securing the OS and web server. For that, I am looking at CIS (Center for Internet Security) and SCW (Security Configuration Wizard) templates. I am also using IISLockdown to further tighten up the system. Second, following vendor guidance to secure the application. Microsoft has excellent whitepapers that detail their security guidance. Finally, I am testing the implementation. This means using tools such as Webscarab and the skills I learned from the SANS AUD507 course.

In sum, I think it is important that network administrators include InfoSec as part of their project plans and ongoing maintenance. InfoSec professionals should use this time wisely to check the OS, web server, and application. The first time around, we play the part of the architect designing the locked down building. The second time around, during maintenance, we play the part of the night watchman, rattling the doors to make sure they are still closed and locked.

Related Links:

Center for Internet Security

http://www.cisecurity.org/

Security Configuration Wizard

http://www.microsoft.com/windowsserver2003/technologies/security/configwiz/default.mspx

How To: Use IISLockdown.exe

http://msdn2.microsoft.com/en-us/library/aa302365.aspx

My security awareness training began on 1997-04/08. That is when the company that I worked with, ISC, came down with a bad case of the Monkey.B virus.

At ISC, we used several boot repair floppies. Many of these I created myself. They ran batch repair jobs to handle minor things like diagnostics and system burn-in. We had no policy for scanning the boot floppies for viruses. Never really occurred to us, for some reason. Then one day — April 8th — I noticed that a client’s computer had suddenly began acting strange.

Over the next ten days, we realized that all of our boot floppies had been infected with an as of yet unknown varient of Stoned.Monkey. Both McAfee and Dr Solomons failed to recognize this varient. F-Secure’s tool did, thankfully, and we were able to recover the client’s machine. In the next few weeks, we paid housecalls to our clients … many of whom we had infected during our diagnostic work.

With that as a background, I found it interesting that rootkits have returned to mbr infections.

Excuse me sir: there’s a rootkit in your master boot record
http://www.theregister.co.uk/2008/01/09/mbr_rootkit/

FIX attacks. As a financial firm, we are heavily reliant upon the FIX (Financial Information eXchange) protocol for buy-side trade execution. Security researchers have identified several concerns with the FIX protocol. The primary concern for my firm is trade errors and trade delays. Much of my security infrastructure relies upon data encryption, protocol filtering, and traffic isolation. All of these mechanisms come into play with the FIX network, as each connection must be isolated and each trading partner secured separately.

J Wolfgang Goerlich

http://www.darkreading.com/document.asp?doc_id=142127&page_number=5
https://www.blackhat.com/presentations/bh-usa-07/Goldsmith_and_Rauch/Presentation/bh-usa-07-goldsmith_and_rauch.pdf

(Thanks to Nathan Ouellette for the email on this issue.)

Happy new year’s! Here is a quick look at what the top 3 security issues to watch for in 2008.

The profit motive is driving two forces in the attacker community. First, attackers are getting sophisticated and better trained. Second, attackers are getting specific and focused. Consequently, watch for highly targeted attacks. These resist traditional signature-based protection because they are very rare and specialized. They bypass most of our preventive, detective, and corrective software controls. We are very vulnerable to never-before-seen attack patterns.

Attacks on application and driver software will also increase. As operating systems progressively improve security, attackers will turn to applications’ soft underbelly. Many application vendors are unprepared for this sort of unwanted attention. The same can be said of hardware manufacturers. Worse, while applications run in user mode, hardware drivers run in kernel mode. This means that a compromised driver gives the attacker full control.

So think targeted attacks against poorly written drivers. Now when we talk about operating systems, with software and drivers, we usually picture traditional computers. Yet this is quickly changing as things become computerized. Everything from printers to pacemakers is becoming fair game. Thus another security concern to watch is vulnerable embedded devices and equipment.

I am not suggesting the future will be doom and gloom. There are many improvements underway. As I mentioned, operating systems continue to evolve and are becoming tougher all the time. Look for anti-virus vendors to shift from code signatures and blacklists to other heuristics, such as behavior modeling and whitelists. Finally, though they are in their heyday now, look for botnets to shrink and perhaps even extinguish in the next five years.

Some things will get worse. Some things will get better. Yet one thing will remain the same: InfoSec continues to be the premier IT challenge.