Tuesday, August 11, 2009

Securing Digital Content: Part I

I will post no code for this blog entry so that I can answer the question of a friend of mine :  How does a normal person take reasonable steps to safeguard sensitive digital content in this day of repeated sophisticated instrusions, penetrations, institutionalized hacking and institutionalized snooping? This is a long subject that would require more than just one blog entry. Here are some (random or not) thoughts: 

Part I Strategies
 I would answer the strategy for maintaining content security like this:
(1) Assume data loss or data theft. Develop a strategy not just to defend against data loss/theft but to recover from it.
(2) Understand the "big" picture. Take some time to understand just how insecure digital data now is for all of us, including journalists, businesses, corporations, nation-states. Read James Bamford's "The Shadow Government" or Misha Glennys "McMafia"
(3) Have a reasonable picture of your enemies and how determined they would be to find your content or stop you from owning it.
(4) Remember the famous (and ancient) network adminstrators maxim: "There are only two kinds of computer users: Those who have lost data and those who will." Always back-up your work. Always work with a net.
(5) Lower your "personal attack surface". Two separate strategies come to mind:
 (a) Confuse possible threats through secrecy, security, iconoclastic behavior, obfuscation and misdirection. (e.g. Keep a 'cover' or 'alibi' or 'grey' lifestyle, own many small computers, own multiple phones but don't always carry them, take public transport to busy malls to work, cultivate unpredictable behavior patterns etc. )
 (b) Become involved and well-known in your community and tribe: develop friends, watchers, and confidants. Keep a respected public content profile on a Blog. Attend your block watch, neighborhood meetings, have your neighbors over for dinner etc.
These two strategies may be more compatible than apparent...
(6) If something feels wrong to you, it probably is. If you don't feel like filling out some Facebook survey that asks for the "top twenty things people don't know about you" your life may well be more secure. Hackers often make up password lists of details from peoples personal lives.  Ask your medical professional exactly why he needs your Social Security number on that form. Despite recent HIPPA laws, medical information is notoriously insecure. The list goes on: too personal strangers, tele-funders from not well-known organizations asking for your credit card numbers.  Limit the leakage of critical personal information. Often, no one else needs to know. Resist the urge to converse too personal details to strangers.
(7) Don't underestimate the threats. But don't spend too much time worrying about them either. It is well-known that successful personal security always involves intuition and spontaneity. Both are dimmed by too much concern.
  
Part II Safe Computing Practices
As for generally accepted computing security practices, if I had to protect sensitive content I would:
(1) read any number of sites that give excellent recommendations on "safe computing practices" from the NSA to FBI to CERT to SANS to SLATE and USE THEM.
(2) understand my firewall, anti-virus, security templates and encryption suites well and USE THEM.
(3) understand my Operating System/Application suite really well. Monitor Operating System/Application security flaws and update as prescribed.
(4) review my firewall, syslog, eventviewer, anti-virus, and web logs every week and attempt to profile both my audience and possible threats from collating all log information.
(5) use product vendors I believe in for my OS, Applications, firewall, AV, encryption suites. Consider using "open-source" platforms and applications whose code is well-reviewed.
(6) if possible or practical, I would store a non-digital copy of protected content in multiple safe locations to protect from disaster.
(7) not keep secure information or sensitive content in your e-mail. Most e-mail is exchanged in 'clear text' across the wire. Most e-mail stores are not kept in 'data vaults' although some e-mail software will offer you this option.
(8) try to remember that data-loss is multi-faceted and often physical in nature. More data may be lost from stolen laptops in America than through network intrusions: Buy a vault and USE IT. Buy multiple deadbolts and USE THEM. Be careful with your laptops and portable drives when you are in a crowd or public place. (See Part IV, suggestion (2) below.)

True Story: I once heard a friend of mine discuss how the local PD called upon to help him break the encryption on a drive of an uncommon real-time UNIX OS that belonged to a narcotics trafficker.
The dealer had gone to some lengths to use a rare OS with encryption of which few people would have technical experience. But once the local PD had physical control of the box...game over....

Part III More Computer Security Practices
Some more computer security suggestions for content protection:
(1) Receive e-mail in plain text always. Consider sending digitally signed e-mail. 
(2) Encrypt your laptop and hard drives with third party encryption.
(3) Understand file and logon security for your Operating System and deploy and use them.
(4) Deploy host and network firewalls and a honeypot. Consider firewalling different segment of your network. Lately, I like the concept of these new UTM (Unified Threat Modeling) firewalls from NetGear and other vendors...
(5) Learn to sniff and review traffic everywhere you go. There's something satisfying about actually reviewing network traffic as you work on the network. Something like surveying the crowd on the street you are walking on...
(6) Consider carrying a small portable hardware firewall for your laptop.
(7) Get in the practice of quickly reformatting an up to date version of your OS if you feel the least bit quesy about your OS behavior. [This tip implies an excellent data back-up habit and some patience with OS installation.].
(8) Wireless is still a risk, especially if unencrypted. If you use it, use a VPN or encryption for sensitive communication and the highest strength encryption you can afford. Beware of "rogue" public hot spots that steal information.
(9) Use OpenSSH for your network communication as much as possible, especially across networks you don't control or own.
(10) Get in the habit of using 21 character plus passwords and changing them often. Yes, you can.
(11) Regardless of whether you run Windows or UNIX, don't take unneccesary sharing or open port or remote administration risks. 'Lock down' the most expensive version of Windows you can afford (e.g. Vista Ultimate). 
[Note: Securing Windows or UNIX requires some effort and thought and training. The use of a consultant may be advisable.]

Part IV Offbeat Ideas?
On the "inventive" or "offbeat" side, if I had to protect sensitive content I might:
(1) Store everything on an old, cheap OpenBSD box that never touches the internet. Run only OpenBSD approved packages.
(2) Buy a Nokia 810, and install and configure iptables. Use it to Skype with your friends off some random wireless connection instead using a cell-phone. Carry it in your jacket pocket and use it instead of a laptop.
(3) Use an iconoclastic Linux distro designed for security - 'Back-Trax' comes to mind...
(4) Surf and collect e-mail on a thumb drive from a bootable Linux distro. Then boot back into an OpenBSD, Linux, Debian,Ubuntu laptop that has no networking at all for your "protected content".
(5) Or you could do the converse: Surf on your hard drive box, boot into a Linux DVD distro, mount a "secure" thumb drive or SD drive for storing sensitive content.
(6) Keep two sets of content: One that can be "found" by your enemies (after some work) and one that is "hidden".  For example,thumb-drives are easy to purchase, back up, and/or store on your person. You could leave decoys lying around with "disinformative content" for when the spooks do a "sneak and peek" at your apartment.
(7) Set up a surveillance system around your home.
(8) Teach yourself to hack and spy. Nothing will make you more paranoid and careful than knowing the "arts of the enemy". Actually, nothing will intimidate your enemies more than aggressive "back-tracking" of their hacking and spying attempts. 
(9) Live in the most populous neighborhood you can stand. San Francisco's China Town comes to mind. It's hard to follow one person consistently in a crowd.
(10) Publish some of your most problematic secret content on a blog, similar to what the Electronic Freedom Foundation does every month. Nothing makes sensitive content less so than publicity. Sometimes, nothing makes a holding a secret less dangerous than sharing it. 

AND THE NUMBER ONE WAY TO PROTECT SENSITIVE CONTENT IS...
[Live without any. Wasn't life simpler without computers? :-)] 

Monday, August 3, 2009

Parsing Vista Firewalls: Part V


When combined with cmd.exe you can populate a logparser query file with cmd.exe variables. The datagrid output of log parser allows for "pretty". The chart output requires a licensed copy of MS Chart output dll.  A little knowledge of SQL takes you quite a long way with Log Parser.

:: must delete "#Fields" from pfirewall.log first for correct field parsing.
@echo off
set field=%1
set filename=%2
echo SELECT %field%, COUNT(*) > OrderByFieldGroupByCount.sql
echo FROM 'C:\Windows\System32\LogFiles\Firewall\%filename%' >> OrderByFieldGroupByCount.sql
echo GROUP BY %field% >> OrderByFieldGroupByCount.sql
echo ORDER BY COUNT(*) DESC >> OrderByFieldGroupByCount.sql
"C:\Program Files (x86)\Log Parser 2.2\LogParser.exe" -i:TSV file:OrderByFieldGroupByCount.sql -q:on -iSeparator:spaces -fixedSep:OFF -nSkipLines:3 -o:datagrid

:: must delete "#Fields" from pfirewall.log first for correct field parsing.
@echo off
set field1=%1
set field2=%2
set filename=%3
echo SELECT %field1% , %field2% , COUNT(*) > OrderByFieldGroupByCount.sql
echo FROM 'C:\Windows\System32\LogFiles\Firewall\%filename%' >> OrderByFieldGroupByCount.sql
echo GROUP BY %field1% , %field2% >> OrderByFieldGroupByCount.sql
echo ORDER BY COUNT(*) DESC >> OrderByFieldGroupByCount.sql
"C:\Program Files (x86)\Log Parser 2.2\LogParser.exe" -i:TSV file:OrderByFieldGroupByCount.sql -q:on -iSeparator:spaces -fixedSep:OFF -nSkipLines:3 -o:datagrid

Saturday, August 1, 2009

Parsing Vista Firewall: Part IV

Microsoft's logparser.exe use sql query syntax to parse many different log formats.  Vista's firewall most reasonably resembles at TSV log file format. However, it takes some work with logparser.exe to get the correct parameters as below.  The third or 'header' line row needs  the words "#Fields" removed from the file for accurate field recognition.

LogParser "SELECT * FROM 'pfirewall.log' WHERE ( action = 'ALLOW' AND protocol = 'UDP' AND path = 'RECEIVE' AND src-ip <> '127.0.0.1' ) " -i:TSV -iSeparator:spaces -fixedSep:OFF -nSkipLines:3

Filename RowNumber date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
--------------------------------------------------- --------- ---------- -------- ------ -------- --------------- --------------- -------- -------- ---- -------- ------ ------ ------ -------- -------- ---- -------
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 7105 2009-07-11 19:56:59 ALLOW UDP 192.168.0.4 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 7107 2009-07-11 19:56:59 ALLOW UDP 169.254.172.113 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 8046 2009-07-11 21:56:36 ALLOW UDP 192.168.0.4 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 8047 2009-07-11 21:56:36 ALLOW UDP 169.254.172.113 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 8316 2009-07-11 22:03:29 ALLOW UDP 169.254.172.113 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 8353 2009-07-11 22:06:18 ALLOW UDP 192.168.0.4 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
C:\Program Files (x86)\Log Parser 2.2\pfirewall.log 8355 2009-07-11 22:06:18 ALLOW UDP 169.254.172.113 239.255.255.250 51493 1900 0 - - - - - - - RECEIVE
....