Minggu, 20 Mei 2012

Blender Banana Bread Recipe - The Quickest and Easiest Way to Make Banana Bread



I am always looking for the cheapest, fastest and easiest way to do things. I think I have it perfected as far as banana bread goes. Below the recipe ingredients I will have more detailed instructions with a bit of information

Read article »

Senin, 14 Mei 2012

SEC Guidance Is a Really Big Deal

In November I wrote SEC Guidance Emphasizes Materiality for Cyber Incidents, my thoughts after reading an article by Senator Jay Rockefeller and former DHS Secretary Michael Chertoff. They explained why the CF Disclosure Guidance: Topic No. 2, Cybersecurity issued by the SEC in October is a big deal.

Since then I attended a conference on Director's and Officer's insurance in Connecticut, and spoke on a panel about that SEC guidance. During the conference I learned that the SEC guidance isn't a big deal -- it's a really big deal. We're talking a game changer, potentially on three fronts. Here's what I heard at the conference.

  1. First, lawyers who read the language in the SEC guidance treated it as a "stop whatever you're doing and read this" moment. The lawyers I spoke to said the SEC guidance absolutely defined new reporting duties for companies, despite talk of it being merely a "clarification" or restatement of existing guidance.

    Clients bombarded insurance firms asking what language they should use in their SEC disclosure documents. They asked "what are other companies saying? What should we say?" The firms noted similar boiler plate shared among clients, most of which insufficiently met the SEC's requirements.

    One lawyer I spoke with said she expects the SEC to give publicly traded firms a "one year pass" before bringing enforcement actions against them for insufficiently outlining digital risk, pre- and post-breach.

  2. Second, the SEC language will encourage shareholder lawsuits against companies by disgruntled parties who believe boards are not disclosing risks and actual breach details to investors. This will probably not be the primary cause for a suit but it will likely be one of other factors a shareholder action uses to show that a board is not fulfilling their duties to investors.
  3. Third, the SEC language may prompt whistleblower reports from dissatisfied IT and security staff to organizations like the SEC Office of the Whistleblower. (That is a real organization!) In the seven weeks beginning with this new office's launch in August 2011, parties reported 334 tips from 37 states and 11 countries, with successful enforcement actions in up to 30% of cases.

    Although it doesn't appear that this new office has paid any whisteblowers yet, it is apparently gearing up to do so. Imagine a case where security staff believes that management is not treating a breach as the staff thinks it should be treated, and decides to report the incident to the SEC -- with the possibility of a payout waiting!

Right now Congress doesn't seem to think that the SEC rules are working. Joe Menn reported in Hacked companies still not telling investors the following:

At least a half-dozen major U.S. companies whose computers have been infiltrated by cyber criminals or international spies have not admitted to the incidents despite new guidance from securities regulators urging such disclosures.

Top U.S. cybersecurity officials believe corporate hacking is widespread, and the Securities and Exchange Commission issued a lengthy "guidance" document on October 13 outlining how and when publicly traded companies should report hacking incidents and cybersecurity risk.

But with one full quarter having elapsed since the SEC request, some major companies that are known to have had significant digital security breaches have said nothing about the incidents in their regulatory filings.

Now Senator Rockefeller is taking a closer look as reported by Jennifer Martinez of Politico this week:

Senate Commerce Chairman Jay Rockefeller thinks the SEC needs to ensure hacked companies are adequately informing their investors about when they suffer a security breach or cybersecurity risk that could jeopardize their financial standing.

The West Virginia Democrat wants the full commission to issue guidance for companies — right now they only have staff-level instructions — on when they have to report cyber breaches or threats and what steps they’re taking to minimize the risks.

“It’s crucial that companies are disclosing to investors how cybersecurity risks affect their bottom lines, and what they are doing to address those risks,” Rockefeller said in a statement to POLITICO.

Rockefeller will soon introduce an amendment that calls on the SEC to issue interpretive guidance on when companies must disclose cybersecurity risks and intrusions. Staffers for the Commerce Committee are finalizing the amendment and aim to introduce it before Sen. Joe Lieberman’s (I-Conn.) cybersecurity bill goes to the floor.

This is the sort of activity that I think is going to mark a sea change in digital security over the coming years. I don't expect engineering or technical developments to have anywhere near the same level of impact as issues that involve legislators, lawyers, insurers, and financiers. Stay tuned!

Use Gmail as a GTD tool (Getting Things Done and using Gmail more productively)




Most of us have probably used email more than a handful of times to remind ourselves to do something, or as a shopping list of sorts. I recently discovered a way to help me be more organized with my emails and tasks using Gmail. It is quick and easy to do.

I will show you how to get important emails and tasks at the top of Gmail, so you will always see (and never forget) the most pressing things in your inbox.

Read article »

Rabu, 09 Mei 2012

Passwords Still the Weak Link in the Chain

Networks are only secure as their weakest part, and time and time again, the weakest part of any network system is the user. Weak passwords are by far the easiest aspect of network security to hack, and despite repeated calls by security experts for people to tighten up their password habits, password vulnerability is as bad as it has ever been.

Gaining access to people’s passwords can be extremely simple, primarily because people just don’t listen to advice. Because so many people use weak or recycled passwords, a hacker only needs to determine one person’s login to gain access to an entire network and the great bounty of data therein. Virtually every high profile hack is down to a single user having a weak password; from online retailer Zappo, who earlier this year had the personal details of 24 million users stolen, to global intelligence firm Stratfor that really should have known better, but recently lost 860,000 user names and email addresses to hackers.

Password security can be extremely difficult for a big network to manage, primarily because it requires policing everybody with access, from the website designers and administrators, to the marketers who are in charge of PPC management and Adsense campaigns, and it only takes one person not to take security seriously for the whole network to become vulnerable.

Seven deadly password sins

People are creatures of habit and nearly a fifth of people still commit one of the seven most common sins for generating passwords:
They use the name of their partner, child or pet, perhaps followed by a digit to adhere to the alpha/numerical construction (usually a 1 or 0). These days with everybody having their life laid bare on social networking sites, it doesn’t take long to learn the name of a family pet, child or spouse.
The same is true of people’s date of birth, either the user or their partner/child/pet.
People often use the last four digits of their social security or employee roll number. These details are perhaps more difficult to get hold of, but not impossible.
Amazingly 123, 1234 or abcd1234 are still common password combinations used by people.
Likewise, “password” or “pa55word” (to get that alpha/numerical combination) is another commonly used combination.
Again, Facebook grants easy access to a user’s favorite sports team, which is another common password sin.
Then there are the generic one-word passwords of “god” “love” “money” “access” etc, which are all common strings.

Repetition

Even if somebody follows the protocol for creating a strong password and uses upper and lower case, number and letters, and keeps the string as random as possible, there is a chance that after going through all that effort, they are probably going to use this same password for a whole host of other web activities. While gaining access to a work VPN or bank account is going to take a lot of effort, some sites, such as forums or online retailers, won’t have such strict security. If a hacker gains access to these websites and figures out a user has quite a strong password, then chances are they are using the same string to gain access to their work network, bank or other secure site.

Hear no evil

Despite the repeated high profile attacks, the loss of millions of people’s personal data each year, and the persistent mantra of the importance of strong passwords from network bosses, people just aren’t listening. It isn’t even as if the internet is a new thing. People have been relying on usernames and passwords for decades, but it seems they just won’t listen. There are probably a couple of reasons for this, and they both boil down to human nature.

Firstly, people think it will never happen to them. Hacking is like being mugged, both in the material loss that can result and in the fact that people think it only happens to others. It isn’t until somebody actually gets hacked that they start to take passwords seriously, but of course, by then it is too late. Secondly, people are inherently lazy. Generating new passwords all the time and having to remember them is not fun, and most people have better things to do, which is why so many choose weak and easy to remember passwords or recycle older ones.

Until people start realizing the importance of good password protocol, high profile hacks will continue unabated. Perhaps there will come a time when virtually everybody has suffered some form of hacking attack at least once, by which time, password security may at last become as important a security concept to people as protecting their wallet or locking their front doors at night. Until then, weak passwords are by far the easiest way in to a network for any hacker.

The Hacka Man

Senin, 30 April 2012

Get-Winevent Part IV: Querying the Event Log for 'Filtering Platform Connection' Information (Part A)


The command:

'auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable'

enables the "Filtering Platform Connection" security counter on Windows 7. The "Filtering Platform Connection" gives your event logs access to the following counters:

Filtering Platform Connection           Success and Failure
  • Object Access Filtering Platform Connection 5150 The Windows Filtering Platform has blocked a packet. Windows 7, Windows Server 2008 R2
  • Object Access Filtering Platform Connection 5151 A more restrictive Windows Filtering Platform filter has blocked a packet. Windows 7, Windows Server 2008 R2
  • Object Access Filtering Platform Packet Drop 5152 The Windows Filtering Platform blocked a packet. Windows Vista, Windows Server 2008
  • Object Access Filtering Platform Packet Drop 5153 A more restrictive Windows Filtering Platform filter has blocked a packet. Windows Vista, Windows Server 2008
  • Object Access Filtering Platform Connection 5154 The Windows Filtering Platform has permitted an application or service to listen on a port for incoming connections. Windows Vista, Windows Server 2008
  • Object Access Filtering Platform Connection 5155 The Windows Filtering Platform has blocked an application or service from listening on a port for incoming connections. Windows Vista, Windows Server 2008
  • Object Access Filtering Platform Connection 5156 The Windows Filtering Platform has allowed a connection. Windows Vista, Windows Server 2008
  • Object Access Filtering Platform Connection 5157 The Windows Filtering Platform has blocked a connection. Windows Vista, Windows Server 2008
  • Object Access Filtering Platform Connection 5158 The Windows Filtering Platform has permitted a bind to a local port. Windows Vista, Windows Server 2008
  • Object Access Filtering Platform Connection 5159 The Windows Filtering Platform has blocked a bind to a local port. Windows Vista, Windows Server 2008
This script, which uses some Powershell 3.0 features, produces the output far below (abbreviated) by parsing the output from EventID 5156 ("allowed connection"). The loops are structured to allow 'findstr' to dig out 'subfield' information. 'Select -unique' functions to find unique addresses (or ports):

[array]$a=Get-WinEvent -FilterHashTable @{LogName='Security';ID=5156;StartTime=$StartTime}
$UDA_count=$a.count
[array[]]$b=$a.Message | findstr 'Destination' | findstr 'Address'
$Global:UDestAddress=($b | Select -unique) | sort

The script takes an extremely long time to run on my five core laptop. These scripts (1,2) are optimized a bit more to search for only 5156 Events. The global variables in the script would be suitable for parsing against lists of allowed ports, allowed or blocked IPs. The Script can be used as a format for other counters as well. Several features from Powershell 3.0 are used in this script including the ability of Powershell 3.0 to 'automatically unroll' an entire array for a certain property (e.g. '[array[]]$b=$a.Message'). I could dearly use a much faster Powershell method to dig 'subfield' information out of the Message field than double piping that information to 'findstr'. The issue is that a single day of network activity generates ten of thousands of kernel security counters.  An alternative to limit the amount of information returned might be to use the '-max' [number of events] parameter:


#[per day]:
$StartTime=(Get-Date) - (New-TimeSpan -Day $days_from_now)
[array]$a=Get-WinEvent -FilterHashTable @{LogName='Security';ID=5156;StartTime=$StartTime}


#[per event]
[array]$a=Get-WinEvent -FilterHashTable @{LogName='Security';ID=5156} -max 1000

$count=$a.count
$StartTime=($a[($count) - 1].TimeCreated)



It should also be pointed out that the ID 'filterhashtable' parameter will take a range as so:

$a=Get-WinEvent -FilterHashTable @{LogName='Security';ID=@(5150..5159)}

Sample output from this script specific to Event ID 5156:

PS C:\ps1> get-5156 100000
Count of Unique EventIDs, Destination Address, Source Address, Destination Ports from 04/30/2012 21:19:32 :
 1 Unique Event IDs out of 336
 26 Destination Addresses out of 336
 4 Source Addresses out of 336
 13 Destination Ports out of 336

EventIDs:
5156

DestinationAddress:
10.10.10.1
127.0.0.1
173.194.33.11
173.194.33.15
173.194.33.40
173.194.33.57
173.194.33.6
173.194.33.9
173.194.79.139
173.194.79.191
192.168.0.1
192.168.0.11
192.168.0.255
255.255.255.255
65.55.87.153
74.125.127.106
74.125.127.191
74.125.127.95
74.125.127.99
74.125.224.102
74.125.224.139
74.125.224.69
74.125.224.72
74.125.224.79
74.125.224.96
85.13.200.108

SourceAddress:
127.0.0.1
192.168.0.11
192.168.0.255
239.255.255.250

SourcePort:
7
8
500
00
3
152
4

995
010
330
404

Sabtu, 21 April 2012

Clowns Base Key Financial Rate on Feelings, Not Data

If you've been reading this blog for a while, you know I don't think very highly of mathematical valuations of "risk." I think even less highly of the clowns in the financial sector who call security professionals "stupid" because we can't match their "five digit accuracy" for risk valuation. We all know how well those "five digit" models worked out. (And as you see from the last link, I was calling their bluff in 2007 before the markets imploded.)

Catching up on last week's Economist this morning I found another example of financial buffoonery that boggles the mind. The article is online: Inter-bank interest rates; Cleaning up LIBOR -- A benchmark which matters to everyone needs fixing:

It is among the most important prices in finance. So allegations that LIBOR (the London inter-bank offered rate) has been manipulated are a serious worry.

LIBOR is meant to be a measure of banks’ own borrowing costs, and is used as the foundation for a host of other interest rates. Everyone is affected by LIBOR: it influences the payments made on mortgages and personal loans, and those received on investments and pensions.

Given its importance, the way LIBOR is calculated is astonishingly flimsy. LIBOR rates are needed, every day, for 15 different borrowing maturities in ten different currencies. But hard data on banks’ borrowing costs are not available every day, and this is the root of the LIBOR problem.

The British Bankers’ Association (BBA), responsible for LIBOR, gets around it by asking banks, each day, what they feel they should pay to borrow.

So LIBOR rates—and the returns on $360 trillion of financial contracts related to them, five times global GDP—are based on best guesses rather than hard data.

Let that sink in and forget about what you learned in business school or economics classes. LIBOR isn't based on actual rates; it's based on feelings!

The next part of the article talks about suspicions that banks manipulate this broken process to the advantage of the financial sector.

The remainder offers recommendations for improvement:

[T]he BBA should revamp LIBOR to ensure it is simple, transparent and accountable. These principles suggest LIBOR should be based on actual inter-bank lending, with any gaps filled in with the help of statistical techniques. Banks’ own guesses should be used as a last resort, not the first.

And regulators should collect data that could help spot LIBOR cheats: banks should be required to submit information on other banks’ borrowing costs, as well as their own. Regulators could cross-check submissions against hard data on banking-sector risk, and publicly report LIBOR abusers.

Keep this system in mind the next time a so-called "master of the universe" offers a lecture on measuring risk in digital security.

Rabu, 04 April 2012

Salvaging Poorly Worded Statistics

Today I joined a panel held at FOSE chaired by Mischel Kwon and featuring Amit Yoran. One of the attendees asked the following:

At another session I heard that "80% of all breaches are preventable." What do you think about that?

My brief answer explained why that statement isn't very useful. In this post I'll explain why.

The first problem is the "80%." 80% of what? What is the sample set? Are the victims in the retail and hospitality sectors or the telecommunications and aerospace industries? Speaking in general terms, different sorts of organizations are at different levels of maturity, capability, and resourcefulness when it comes to digital security.

In the spirit of salvaging this poorly worded statistic, let's assume (rightly or wrongly) that the sample set involves the retail and hospitality sectors.

The second problem is the term "breach." What is a breach? Is it the compromise of a single computer? (What's compromise? Does it mean executing malicious code, or login via stolen credentials, or...?) What is the duration of the incident? There are dozens of questions that could be asked here.

To salvage this part, let's assume "breach" means "an incident involving execution of unauthorized code by an unauthorized intruder" on a single computer.

The third problem is the word "preventable." "Prevention" as a concept is becoming less useful by the second. Think about how an intruder might try to execute malicious code against a victim. Imagine a fully automated attack that happens when a victim visits a malicious Web site. An exploit kit could throw a dozen or more exploits against a browser and applications until one works. Are they all non-zero day, or are some zero day? Again, many questions beckon.

To salvage the end of the original statement, let's translate "preventable" into "exploitation of a vulnerability for which a patch had been publicly available for at least seven days."

Our new statement now reads something like "In the retail and hospitality sectors, 80% of the incidents where an unauthorized intruder successfully executed unauthorized code on a single computer exploited a vulnerability for which a patch had been publicly available for at least seven days."

Isn't that catchy! That's why we heard shortcuts like the original statement, which are basically worthless. Unfortunately, they end up driving listeners into poor conceptual and operational models.

The wordy but accurate statement says nothing about preventability, which is key. The reason is that a determined adversary, when confronted by a fully patched target, may decide to escalate to using a zero-day or other technique for which patches are irrelevant.