Mythic Monday – The Song of Roland
- At February 23, 2009
- By Josh More
- In Mythology
0
The Song or Roland tells the tale of King Charlemagne and his knight Roland. The tale is long and complex (and nicely summarized here), but the important thing is near the end.
Roland and his knights are ambushed. There’s possibility of success, but they keep fighting on. Roland has but one option remaining, and that is to sound his horn and summon reinforcements. However, to require help would not honorable, and Roland would rather die than be dishonored. Things get so bad that Roland’s friend implores him to blow on his horn three times, and Roland in his pride, chooses not to.
Then, at the end, when all is truly lost, Roland finally sounds his horn and dies with the effort. The king hears and comes to the battlefield and avenges the dead.
So, what can we learn from this?
I think that the most important lesson is pretty obvious: blow the horn before everyone dies. Or, in modern vernacular, swallow your pride and ask for help.
It’s no news to anyone that a lot of businesses are struggling right now. The economy is in a state of turmoil, and while a lot people say that you can make money whether the stock market moves up, down or sideways, the simple fact is that things are hard when the future is even less predictable than usual. Existing vendors may change your credit terms, clients may demand a higher value from you for what they’re paying. Competitors may choose to compete in ways that may not be ethical or fair.
What can you do about this? There’s one simple option: ask for help.
There is a lot of talk about business being cut-throat and numerous stories about business partners that took advantage of one another. However, at least in the small business market, the opposite is also true. People help each other out.
Sure, there are high-priced consultants who will come in and give you advice. There are also well-intentioned friends who might help you out for free. But don’t forget about the tons of mid-range business people that are willing to lend a hand for modest fees and/or the trading of services. Odds are that there is a relatively workable solution to your business problem and a cheaper or more efficient way to do things. However, if you never ask for help, you may never find them.
There is also no point of waiting until everyone around is dead or dying (or laid off) before you call for help. If you wait too long, your business just serves as a tale of warning to others (much like The Song of Roland, actually).
Remember, we may be competitors, clients or vendors, but we actually are all in this together. It does no one any good to stand by and idly watch as small businesses fall like dominoes. We can help each other out… so long as we know who to help.
Tool Review – ExifTool
- At February 20, 2009
- By Josh More
- In Business Security
- 0
The EXchangable Image File format (EXIF) is a method that image files use to store data about the image. It’s often referenced in relation to the image files producted by digital cameras. These files often store data about the camera that took the photo, the settings of the camera, whether or not the flash went off and other data. This is very useful in categorizing the images.
ExifTool is a neat little tool that allows you to dig into this information. It’s available for Windows, Linux and Mac, and lets you look inside your photos. Let’s look at an example. This is what results in my running the tool against a photo that I took on a recent trip:
$ exiftool dsc_6497.jpg ExifTool Version Number : 7.42 File Name : dsc_6497.jpg Directory : . File Size : 5.9 MB File Modification Date/Time : 2009:02:15 17:50:13 File Type : JPEG MIME Type : image/jpeg Exif Byte Order : Big-endian (Motorola, MM) Make : NIKON CORPORATION Camera Model Name : NIKON D200 Orientation : Horizontal (normal) X Resolution : 300 Y Resolution : 300 Resolution Unit : inches Software : f-spot version 0.5.0.3 Modify Date : 2009:02:15 17:50:13 Y Cb Cr Positioning : Co-sited Exposure Time : 1/320 F Number : 7.1 Exposure Program : Aperture-priority AE ISO : 100 Exif Version : 0221 Date/Time Original : 2009:01:25 23:44:02 Create Date : 2009:01:25 17:44:02 Components Configuration : YCbCr Compressed Bits Per Pixel : 4 Exposure Compensation : 0 Max Aperture Value : 5.7 Metering Mode : Multi-segment Flash : No Flash Focal Length : 400.0 mm Maker Note Version : 2.10 Color Mode : Color Quality : Fine White Balance : Sunny Focus Mode : AF-C Flash Setting : Normal Flash Type : White Balance Fine Tune : -2 Color Balance 1 : 1.8359375 1.35546875 1 1 Program Shift : 0 Exposure Difference : 0 Warning : Bad NikonPreview directory Flash Exposure Compensation : 0 ISO Setting : 100 Image Boundary : 0 0 3872 2592 Flash Exposure Bracket Value : 0.0 Exposure Bracket Value : 0 Crop Hi Speed : Off (3904x2616 cropped to 3904x2616 at pixel 0,0) Serial Number : Image Authentication : Off Tone Comp : Auto Lens Type : D VR Lens : 80-400mm f/4.5-5.6 Flash Mode : Did Not Fire AF Area Mode : Dynamic Area AF Point : Center AF Points In Focus : Center Shooting Mode : Continuous, Auto ISO Auto Bracket Release : Manual Release Color Hue : Mode1 Light Source : Natural Shot Info Version : 0207 Vibration Reduction : On (1) Hue Adjustment : 0 Noise Reduction : Off WB RGGB Levels : 470 256 256 347 Lens Data Version : 0201 Exit Pupil Position : 128.0 mm AF Aperture : 5.7 Focus Position : 0x03 Focus Distance : 59.57 m Lens ID Number : 101 Lens F Stops : 5.67 Min Focal Length : 80.0 mm Max Focal Length : 403.2 mm Max Aperture At Min Focal : 4.5 Max Aperture At Max Focal : 5.7 MCU Version : 107 Effective Max Aperture : 5.7 Sensor Pixel Size : 6.05 x 6.05 um Image Data Size : 6218124 Image Count : 26181 Deleted Image Count : 1307 Shutter Count : 27488 Flash Info Version : 0101 External Flash Flags : (none) Flash Commander Mode : Off Flash Control Mode : Off Flash Group A Control Mode : Off Flash Group B Control Mode : Off Flash Group A Exposure Comp : 0 Flash Group B Exposure Comp : 0 Image Optimization : Custom Multi Exposure Version : 0100 Multi Exposure Mode : Off Multi Exposure Shots : 0 Multi Exposure Auto Gain : Off High ISO Noise Reduction : Off User Comment : (c) Josh More www.starmind.org Sub Sec Time : 55 Sub Sec Time Original : 55 Sub Sec Time Digitized : 55 Flashpix Version : 0100 Color Space : sRGB Exif Image Width : 3872 Exif Image Height : 2592 Interoperability Index : R98 - DCF basic file (sRGB) Interoperability Version : 0100 Sensing Method : One-chip color area File Source : Digital Camera Scene Type : Directly photographed CFA Pattern : [Green,Red][Blue,Green] Custom Rendered : Normal Exposure Mode : Auto Digital Zoom Ratio : 1 Focal Length In 35mm Format : 600 mm Scene Capture Type : Standard Gain Control : None Contrast : Normal Saturation : Normal Sharpness : Hard Subject Distance Range : Unknown GPS Version ID : 2.2.0.0 Compression : JPEG (old-style) Thumbnail Offset : 3388 Thumbnail Length : 9164 Subject : Bird Viewing Area Image Width : 3872 Image Height : 2592 Encoding Process : Baseline DCT, Huffman coding Bits Per Sample : 8 Color Components : 3 Y Cb Cr Sub Sampling : YCbCr4:2:2 (2 1) Aperture : 7.1 Blue Balance : 1.355469 Image Size : 3872x2592 Lens ID : AF VR Zoom-Nikkor 80-400mm f/4.5-5.6D ED Lens : 80-400mm f/4.5-5.6 D VR Red Balance : 1.835938 Scale Factor To 35 mm Equivalent: 1.5 Shutter Speed : 1/320 Thumbnail Image : (Binary data 9164 bytes, use -b option to extract) Circle Of Confusion : 0.020 mm Depth Of Field : 6.28 m (56.59 - 62.87) Field Of View : 3.4 deg (3.55 m) Focal Length : 400.0 mm (35 mm equivalent: 600.0 mm) Hyperfocal Distance : 1125.03 m Light Value : 14.0 Date/Time Original : 2009:01:25 23:44:02.55
As you can see, there is a lot of data here. Far more than you might expect to be in a simple picture. Moreover, I’ve bolded some of the more interesting information. A photographer might be interested in knowing that I used a Nikon d200 to take this photo. I also apparently used an AF VR Zoom-Nikkor 80-400mm f/4.5-5.6D ED lens. Note that there is technical data about not just the focal length and aperture used, but also the maximal and minimal settings for the lens. Note as well that the date appears in numerous places. Now things are getting interesting, as there’s a way to verify that I took the photo when I claim to have done.
After all, I might have fabricated evidence.
So sure, this is good to know, in case I am claiming to have captured Bigfoot, but that doesn’t happen very often in business. However, information leaks do.
Let’s take a quick trip over to Wikileaks and see what we can find:
Over here, we find a nice report titled “UN finds 217 sex abuse claims against blue helmets”. Downloading the fairly nondescript file “OIOS-20070130-01.pdf“, we get:
$ exiftool OIOS-20070130-01.pdf ExifTool Version Number : 7.42 File Name : OIOS-20070130-01.pdf Directory : . File Size : 221 kB File Modification Date/Time : 2009:02:19 22:44:11 File Type : PDF MIME Type : application/pdf PDF Version : 1.5 Page Count : 17 Creator Tool : PrimoPDF http://www.primopdf.com Metadata Date : 2008:04:09 12:54:16-04:00 Document ID : uuid:a3ec6d39-037e-4672-945b-25ce88970721 Format : application/pdf Description : United Nations Organization Mission in the Democratic Republic of the Congo Modify Date : 2008:04:09 12:54:16-04:00 Create Date : 2007:04:12 17:16:25Z Title : Allegations of sexual exploitation and abuse in the Ituri region, Bunia [ID Case No. 0618-05] Creator : PrimoPDF http://www.primopdf.com Author : Date : 01/30/2007 Keywords : monuc, congo, bunia, sexual, exploitation, abuse, ituri Subject : United Nations Organization Mission in the Democratic Republic of the Congo Producer : AFPL Ghostscript 8.54
So, we’ve learned when the file was created (back in April 2007), but it was modified in April 2008. Interesting. We also learn that it originally had a more interesting description and title than “OIOS-20070130-01.pdf”.
But Wikileaks scrubs data in an effort to remain anonymous (well, mostly). What about other information out there? How about we do a quick Google search on intitle:”rfp”+filetype:doc+response, looking for responses to RFPs that might be available. Suppose this searched turned up a document titled “KonnSv11.doc” that just might be an RFP response from a large multinational company that knows a little something about connectivity. Wonder what this document can tell us?
$ exiftool KonnSv11.doc
ExifTool Version Number : 7.42
File Name : KonnSv11.doc
Directory : .
File Size : 508 kB
File Modification Date/Time : 2009:02:12 22:51:53
File Type : DOC
MIME Type : application/msword
Title : COMPANY IPCM RFP Response
Subject : Ver.1.0
Author : Tikeo Homado
Keywords :
Template : NormalAnglais
Last Saved By : Tikeo Homado
Revision Number : 18
Software : Microsoft Word 8.0
Total Edit Time : 6.9 hours
Last Printed : 2000:03:21 02:34:00
Create Date : 2000:04:20 02:06:00
Modify Date : 2000:04:21 09:39:00
Page Count : 1
Word Count : 13019
Char Count : 70516
Security : 0
Company : COMPANY
Lines : 1221
Paragraphs : 1012
Char Count With Spaces : 91437
App Version : 8 (0e84)
Scale Crop : 0
Links Up To Date : 0
Shared Doc : 0
Hyperlinks Changed : 0
Title Of Parts : COMPANY IPCM RFP Response
Heading Pairs : Title, 1
Code Page : 932
PIDGUID : {91F4D900-FDF2-14D0-BEF0-DC9E29819138}
Hyperlinks : joeLogo2.gif
Comp Obj User Type Len : 20
Comp Obj User Type : Microsoft Word ��
So, we get the name of the person who worked on the RFP. In this case, the same name is listed in the RFP, but it’s not unusual for companies to have an RFP team, with a project manager in charge. Might it be useful to get the names of the key project managers at a competing company? Also, note that we have learned how much time they put into writing the RFP. If, after a few searches, you can find out how much time your competitors spend on responses, might that not be useful?
Let’s look at one last example. If we do a search on intitle:”salary”+filetype:xls, we might expect to find a lot of spreadsheets containing salary data. We might even be right. Were we to find such a file and run our handydandy little tool against it, we might even see:
$ exiftool Salary info over 75000.xls ExifTool Version Number : 7.42 File Name : Salary info over 75000.xls Directory : . File Size : 131 kB File Modification Date/Time : 2009:02:11 23:10:49 File Type : XLS MIME Type : application/vnd.ms-excel Author : sgermon Last Saved By : nshoedinger Software : Microsoft Excel Last Printed : 2008:03:10 13:56:03 Create Date : 2006:12:11 15:48:19 Modify Date : 2008:10:09 12:38:55 Security : 0 Company : JANEDOE App Version : 11 (270f) Scale Crop : 0 Links Up To Date : 0 Shared Doc : 0 Hyperlinks Changed : 0 Title Of Parts : Contract; Benefits, CoDist, 'Contract & Benefits'!Print_Titles Heading Pairs : Worksheets, 2, Named Ranges, 2 Code Page : 1152
The interesting bit here is that the author and the person who last edited the document are different. So, we know that two people know the salaries in excess of $75,000 for this organization. Those names also look a lot like network username names, so we probably also have email addresses and with a bit of work, possibly accounts that we could use to access certain systems. Perhaps these names even have access to the financial data, given that they know salaries.
So, a few questions for you:
- What information are your clients putting out on the Internet about themselves? About you?
- What information are your competitors putting out there?
- What information are you accidentally leaking when you send files around?
- Did you know that exiftool can also be used to SET data as well as read it? Interesting, no?
Do you think you might want to do something about that?
Important Note
It is important to note here that search engines make public a lot of information that probably was not intended to be made public. It may or may not be illegal to access all of this data, but it should be OK to run tools like this against data that you own and find out what you’re leaking.
For my part, I modified some of the data in the exif reports listed above. The format is correct, but it seems wrong to me to propogate someone’s data security mistake just to make a point, especially when the point can be made without doing so. If you start playing with these techniques, I implore you to remember that people on the Internet are still people, and people make mistakes. There’s generally no need to make these mistakes worse for them.
Please, be kind.
Small Business Defense – Patch Management and Defense in Depth
- At February 19, 2009
- By Josh More
- In Business Security
- 0
If you recall from yesterday, you’re in a lot of trouble. You have all these patches coming at you, and you have to apply them quickly but make sure that they don’t break anything. This isn’t easy, but what follows is a simple list of things to check. It’s far from complete, but if you’re not managing your patches already, it’s a step in the right direction.
Do you really need that patch?
Remember that patches fix specific problems in specific pieces of software. You can dramatically simplify the situation by reducing the software that is installed. If you don’t use instant messaging in your business, there’s no reason to have it installed. The same goes for various games and peer to peer applications. Depending on what you do, it may also apply to development tools and office applications. Remember, if it’s there to be exploited, it can’t be exploited.
Is there another option?
Many patches cover specific attack vectors. For example, different applications often listen for connections on specific ports. Sadly, many of them are installed in such a way as to connect with anyone that wants. Thus, if you have a payroll application that listens on port 11235 (eureka) but only needs to be accessed by the CFO, you can lock connections down so that only the CFO can use it. If you do that (and the CFO’s PC is secure), you might be able to get away with excluding or delaying the patch.
Also, many applications run at a higher user level than is necessary. Some people may have administrator rights to their own systems. They may even need them to install software and do their daily jobs. However, do they need them to use Internet Explorer when they connect to Facebook? Probably not. Using a tool like Drop My Rights or avoiding IE alltogether and using Firefox, would mitigate this problem.
Test Quickly
Despite my issues with virtualization, it is a useful technology. If you have a full virtual infrastructure, you can quickly copy a machine, apply a patch, and run a suite of automated tests to see if it works OK. If you’re a bit of risk taker, you can even flip this around and apply the patch as soon as it becomes available, and simply make a copy of the machine in case it does cause problems. That way, you’re protected as quickly as possible.
Deploy Everywhere
Remember, a piece of software should be easily accessed by those that need it, and impossible to access by those that don’t. It’s a bit like your bed. You need to sleep in it. Depending on your living situation, others may need to sleep in it as well. Thus, you need doors so you can get into your house (where you presumably keep your bed). However, you don’t want random people coming in off the street and sleeping in your bed. That’s why you put locks on the doors.
If you only apply your patches on some of your servers, it’s like only locking your front door but leaving your back door hanging open. Eventually, you’ll stumble home exhausted from your day, and find a group of strangers in your bed.
Conclusion
You have to realize that patching is essential, but isn’t enough. You can apply hardening techniques like those above and antimalware techniques like HIPS, as mentioned earlier. You can lock down your network and user rights. There are a lot of other things that you can do as well. However, you have to apply the patches.
There are technologies that can be used to keep things up to date. There are technologies that can be used to automatically test your patches. There are technologies that can help you determine if a particular patch is needed. However, before any of these can be successful, you have to commit to the reality that patches have to be applied as soon as possible, and accept that you are placing your business at risk if you do not.
Small Business Attack – Vulnerabilities and Exploits
- At February 18, 2009
- By Josh More
- In Business Security
- 0
So, by now, I am assuming that everyone around knows the importance of patching their systems when patches comes out. However, the reasons behind the practice aren’t often clear. It gets a bit complex, because a patch can be intended to solve a problem or add a feature. It gets more complex because there are different sorts of problems, only some of which are security related. For the purpose of this post, a “patch” is a small release that is intended to correct a security problem in a piece of software.
So, when these come out, there is generally a known problem in the software. Since it can allow an attacker to do something bad (to the system, the application or the data, generally), it’s known as a “vulnerability”. You’ll hear those of us in the industry natter on far longer than is polite about the different ways to classify these vulnerabilities and which ones are “real” and which ones aren’t.
Really, we’re part of the problem. See, within the security industry, there is a small and vocal minority that think that patching is stupid, and that systems should be designed securely to begin with. Secure systems should only need a patch to add new functionality, and never need one to correct a security problem. They say that people shouldn’t patch at all, and instead should hold software vendors accountable so that their software is designed securely in the first place. If we don’t, we’ll never get secure software.
These people are absolutely correct, and utterly wrong at the same time.
Developing secure software is very hard. It requires that all developers understand security and have enough experience to make the proper design decisions, that project managers will support them when correcting problems causes a release date to slip. It means lots and lots of testing. It means better tools and much longer release cycles.
In the end, it means very slow and very expensive software. The market doesn’t want that. Thus, we have patches.
There is a large and mostly silent majority in the security industry that simply patch every time they become available. They wait for the patches to be released, put them into their test systems and start running tests against them. The often deploy the patches to production on the weekend following the update. Thus, patches are often applied five to twelve days after they are released and cause a minimum of interruption to operations.
These people are absolutely correct, and utterly wrong at the same time.
Patches fix problems, and as we all know, problems come in different flavours and severities. If you treat every problem the same way, you are giving some problems too much attention and, worse, some far too little. This gets us to exploits.
The attackers have tools too. There are tools that scan your systems looking for problems. There are tools that automatically try to take over your system when problems are found. There are tools that cover their traces. These tools are updated too… with patches.
Specifically, when a patch comes out that addresses a security problem, attackers start looking at what the problem fixes, and add functionality to their tools that detect the problem and exploit it with ease. The more urgent the patch (more severe the problem), the more quickly they work to update their tools.
This puts you, the business owner in an interesting position:
- You can’t not patch, as that would leave your business vulnerable.
- You can’t wait too long to patch, as the attackers would slip in, take over, and cover their tracks.
- You can’t patch too quickly, as that could cause problems in operations.
What are you going to do about it?
Security lessons from Nature – Venom
- At February 17, 2009
- By Josh More
- In Natural History
- 0
I am quite certain that it will come as no surprise to you that there are animals out there that are venomous. Generally speaking, they’re the ones that slither around until you walk up to them, at which point they begin doing a remarkable impersonation of a stick. Should you be unwise enough to think “Hey, I need a stick just like that one!” and pick it up, they will suddenly turn around and stab you with long pointy fangs. Then of course, to add insult to injury, they’ll also inject you with venom. These nasty chemicals will course their way through your system causing pain, organ failure and death.
It’s not just the slithery scaly ones that you should be careful of, of course. There are also the ones with far too many legs. These ones lurk in the woods, waiting for you to get distracted by a pretty nature scene, at which point they’ll descend from the trees on long thin threads, land on your neck and bite you. Then, as you’re falling down and writhing in pain, they’ll climb back up the thread and return to their lairs, giggling the whole way. They also like to live in areas where there are no trees, where they’ll conceal themselves in crevices and wait for you to go rock climbing. If you stick a finger in a hand hold, they’ll bite the fingertip, so that when you yank your hand out and fall off the mountain, you have time to watch your hand slowly swell and turn colours before you eventually splat at the bottom.
Then, there are the ones that live in the sea that are venomous all over. Since they swim better than you, they can come at you from all directions. Since you can only look in one direction at a time, you’re pretty much doomed. There are even some that are almost invisible and are one of the most deadly creatures in the sea.
Lastly, even the cute fuzzy critters can be dangerous. From good sized ones that are part duck to rodents that swarm to little monkey-like creatures with poisonous elbows(!), you never know what’s going to get you.
So yeah, the world is a very dangerous place (and it’s even worse if you dare to live in Australia). The only way to be safe is to not go out in it at all. Well, maybe not. Maybe you’re just fated to get bitten and die a lingering painful death. After all, with all these creatures around, everyone dies that way, right?
Right?
What, they don’t?
The lesson to learn this week is one that you already know. Simply put, don’t panic. Yes, there are venomous animals all over, but there are a great many mitigating factors as well. Snakes and spiders actually prefer to be left alone and only bite as a last resort. Even better, most of them aren’t venomous. Scorpion fish and stingrays tend to only bother divers, who generally know the risks and how to avoid them. Also, I can count the number of times I’ve been attacked by a platypus, slow loris or horde of shrews on one hand… and I don’t even need to use my fingers.
The business world is full of security concerns. The threats are real and need to be addressed. However, it can be overwhelming to listen to everyone’s advice and idiotic to ignore it. You have to strike a balance in what you do. It doesn’t make sense to spend a million dollars to protect a $10,000 server. Just like it doesn’t make sense to wear a suit of armor when going rock climbing. The thing is, it also doesn’t make sense to go on a ten mile hike stark naked, smeared with rattlesnake pheromones.
Others have said similar things (Bruce Schneier, Drew McLellan). It really comes down to a simple problem. We’ve had millions of years to come to terms with the risks of living in the world, but only about twenty years to deal with the risks on the Internet. We don’t know how to strike the balance between being naked out there and armoring up ridiculously. We can’t intuitively recognize that a pair of good hiking boots is “good enough”.
There are all sorts of mathematical models that we use in the industry to analyze risk to do cost justification to senior management. They mostly work, but when you down to it, it’s like trying to come up with a mathematical model that says things like “wear gloves when rock climbing” and “don’t pick up snakes in the woods”. They’ll never going to be perfect.
So, what’s the right solution?
I’m afraid that it’s going to have to depend on the situation. If your organization is structured such that you allocate money on a yearly basis, and that money has to be approved by a board, you probably have to weigh all your options, call in numerous vendors, get position statements from all the middle managers, perform risk and threat analyses and put together a cost justification. Then, once you have a plan to present, you get to try to shoehorn the plan into an ROI model that’s not going to work anyway. Then, if you’re lucky, you get it passed. If you’re not, you’re unprotected for another year.
However, I prefer to work with small business. Then it’s easy to do what I like to call “agile security”. It’s fast, it’s cheap and it’s easy. There’s just one drawback. You have to trust.
Back in the days when people didn’t know which snakes were venomous and which ones were safe to hit with a stick and bring home for dinner, they likely relied on a handful of experts. Some knew snakes. Some knew spiders. Some knew plants: which ones not to eat, which ones were yummy, and which ones were the best ground up into a paste and put on the wound that was made when you ignored the advice of the snake expert.
They didn’t have complex models. They didn’t use a lot of numbers. They just said things like: “Don’t touch that snake. When Og touched that snake, it bit him. Then he ran around in circles for a while, turned purple and died.”
In a similar vein, I offer you this advice:
- Install a firewall that blocks both inbound and outbound traffic. If you don’t, it’s easy for an attacker to get your data or use your system to attack others. When this happens, your business will suffer.
- Run a HIPS product (antimalware or application whitelisting). If you don’t, you’ll get infected and an attacker could do anything they want.
- Don’t give everyone administrator access on your servers. If you do, there’s no control over your systems, and anyone could make a mistake that brings everything down.
- Make sure that more than one person knows the administrator passwords. If you don’t, and that person proves to be untrustworthy, you’ll be locked out.
- Keep your systems patched. Server maintenance is like house maintenance. It’s a LOT cheaper to fix things early.
There are a great many others, of course, but these are a good place to start. If you’re not following any of this advice, pick one and start. Remember, you’re walking around in the woods right now. I know that you can’t afford a suit of armor. I know that you don’t know which boots are best. That’s OK. Here are some sandals. They’re not ideal, but it’s better than what you’ve got.
Let’s work our way up together.
Just in case someone gets here by doing a search and doesn’t care for an essay on I.T. Security, here are some links:
