June 2009

Time is critical in security systems; specifically, having systems know the time  is very important. Adequate clock synchronization is important for:

• Operational Integrity (things happen when they are supposed to happen – backups, tasks, etc.)
• Reproducibility of events (meaningful logs and records)
• Validation of SSL certificate expiration (or other tokens, etc.)
• Correct application of time restricted controls
• Etc.

So, the big question is, what is “adequate clock synchronization”, and how do we achieve it ?

But First, What Time Is It ?

Time itself is of course a natural phenomenon. Just like distance, volume, and weight, the measurements for time are artificial and man-made.  The dominant time standard (especially from a computer and therefore Information Security perspective) is Coordinated Universal Time (UTC). This could probably have been called Universal Compromise Time, as it turns out that getting the whole world to drop their cultural biases, deployed technology, etc. and move to a single time system has been a long and complicated road (and it isn’t over yet).

One major component of UTC is an agreement on what time it in fact is, and how that is determined. Also, there are  questions surrounding how to adjust leap seconds, leap years,  and other “measurement vs reality” anomalies.  Time (and its measurement) is quite complex in itself, but for the purposes of Information Security (system operation, log correlation, certificate expiration, etc.), the good news is that UTC provides a solid time standard.

Now, all we need to do is synchronize our clocks to UTC !
(and adjust for our local time zone…)

Network Time Protocol (NTP)

Network Time Protocol (NTP) is a well established, but often misconfigured and misunderstood, internet protocol. NTP utilizes Marzullo’s Algorithm to synchronize clocks in spite of the fact that:

• The travel time for information passed between systems via a network is constantly changing
• Remote clocks themselves may contain some error (noise) vs UTC
• Remote clocks may themselves be using NTP to determine the time

In spite of this, a properly configured NTP client can synchronize its clock to within 10 milliseconds (1/100 s) of UTC over the public internet. Servers on the same LAN can synchronize much more closely . For Information Security purposes, clock synchronization among systems and to UTC, within 1/5 or 1/10 of a second, should be sufficient.

Classic Misconfiguration Mistakes (and how to avoid them)

The misconfiguration mistakes that folks make tend to be the result of:

• Overestimating the importance of Stratum 1 servers
• Over-thinking the NTP configuration

NTP Servers are divided into Stratums based on what time source. A Stratum 1 server is directly connected to a device that provides a time reference. Some examples of reference time sources include:

• Atomic Clocks
• GPS
• CDMA
• WWVB, DCF77, MSF60

NTP servers which synchronize with a Stratum 1 time source are Stratum 2 servers, with the Stratum number increasing by one for each level.

Big Mistake – Using a Well Known NTP Reference

The most frequent mistake people make when configuring NTP on a server is assuming that they need (or will get the best time synchronization) by using one of the well known atomic clock sources. This tends (thought not always) to be a bad idea because it overloads a small number of servers. Also, a server with a simpler network access path will generally provide better synchronization than a more remote one.

When configuring the NTP protocol, it is a good idea to specify several servers. The general rule of thumb is 2-4 NTP servers. If everyone specifies the same servers, then those servers become overloaded and their response times become erratic (which doesn’t help things). In some cases, an unintended denial of service attack is caused.

Both Trinity College of Dublin, Ireland and the University of Wisconsin at Madison experienced unintended denial of service attacks caused by misconfigured product deployments. In the case of the University of Wisconsin at Madison, NETGEAR shipped over 700,000 routers which were set-up to all pull time references from the university’s servers. NETGEAR is not the only router or product manufacturer to have made such an error.

Enter the NTP Pool…

“The pool.ntp.org project is a big virtual cluster of timeservers striving to provide reliable easy to use NTP service for millions of clients without putting a strain on the big popular timeservers.” quoted from pool.ntp.org

Basically, the NTP pool is a set of over 1500 time servers, all of which are volunteering to participate in a large load-balanced virtual time service. The quality and availability of the time service provided by each of the NTP servers in the pool is monitored, and servers are removed if they fail to meet certain guidelines.

Unless a system itself is going to be an NTP server, then use of the NTP Pool is your best bet 100% of the time. It is a good idea to use the sub-pool that is associated with your region on the globe. Here is ta sample configuration: (/etc/ntp.conf file)

server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org

It may not be necessary for your to run the NTP service itself. Running the ntpdate command at boot and then in a cron job once or twice a day may be sufficient. The command would look like:

ntpdate 0.us.pool.ntp.org 1.us.pool.ntp.org 2.us.pool.ntp.org 3.us.pool.ntp.org

If you do need to install ntp on Ubuntu, the commands are:

sudo apt-get install ntp

and then edit the /etc/ntp.conf file and add the server lines from above. On my OSX workstation, the entire /etc/ntp.conf file is:

driftfile /var/ntp/ntp.drift

server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org

Overthinking the Configuration

The “server” parameter in the configuration file has a number of additional directives that can be specified. These are almost never needed, but can generate a lot of extra traffic on the NTP server. Avoid over thinking the server configurations and avoid using prefer, iburst, or burst.

When Should I Run NTP Service Rather Than Use The NTPDate Command ?

There is almost no downside to running the NTP service. It is very low overhead and generates almost no network traffic. That being said, the only downside to running the ntpdate command a few times a day, is that the clock can drift more. If I were performing an audit, and the shop-practice was to use ntpdate on everything except infrastructure service machines (directory servers, syslog concentrators, etc.), I would accept that practice. I would be more concerned about how time synchronization was being managed on HSMs, directory services, NIDS, firewalls, etc.

When Should I Run My Own NTP Server ?

There are two cases when you should consider running your own server:

• You have a large number of machines that need time services
• You wish to participate in NTP Pool

A Stratum 1 time server appliance or a GPS/CDMA card can be purchased for costs similar to a rack mounted server (of course you will need two). If that is just out of the (budgetary) question, then I would look for the time servers to use authenticated time sources. NIST and several other Stratum 1 NTP providers have servers which are only available to folks who have requested access, and are authenticating to the server. If time accuracy is critical to risk management, and GPS/CDMA is not available, then I would push for authenticated NTP.

Option 3 is acceptable in the vast majority of situations, including cases where logs and events are only correlated locally, or where no compelling need exists.

NTP and Network Security

NTP uses UDP on port 123. This traffic should be restricted in DMZ or other secure network zones to only route to authorized NTP servers. Tools like hping can be used to turn any open port into a file transfer gateway or tunnel.

One option is to set-up a transparent proxy on your firewalls and to direct all 123/UDP traffic to your NTP server or to one you trust. (The risk of the open port involves providing a data path out of the organization, not rogue clocks…)

Resources and More Information

• Wikipedia on NTP
• A Brief History of NTP Time: Confessions of an Internet Timekeeper
• Marzullo’s Algorithm

Cheers,

Erik

Auditing Time…

{ Comments on this entry are closed }

I liked this article about how some corporate IT departments are reacting to the economic downturn. "We're using smaller, lighter and cheaper technologies..." says one CIO.

Being that my employer is a small, nimble, innovative software company, I especially liked this quote from CPS Energy CIO Christopher Barron:

"With software from smaller vendors, it can take 20% to 40% less time to implement, and if it works, it could save you between three and eight times as much. The catch, of course, is that it doesn't always work. But even failing seems to be cheaper than going with the big guys."

I've always heard the adage that 'Nobody gets fired for buying IBM', meaning that even if you spend a little more, you're playing it safe by going with a trusted, well-known name. But the only projects I've ever heard becoming a colossal failure involve solutions from big name vendors with multi-million dollar price tags. And the really cool success stories you hear involve someone accomplishing something great with minimal budget.

Don't get me wrong - I know that many large businesses are run on big name solutions from IBM, SAP, Oracle and the like, but I think we need to be clear that the adage is not an axiom. That is, it's not self-evident. In fact, to some, it might even be nonsensical. Why would it make sense to spend 4x the amount of money to decrease your risk of over-expenditure?

What do you think? Does the adage hold up in today's economy? Will it hold up when we recover? Is it simply a question of finding the right solution for the job, or should it be part of a CIO's objective to put cost out in front of the decision?

{ Comments on this entry are closed }

Posted by Aaron Portnoy
On May 28th, 2009 Microsoft released MS Security Advisory 971778 titled Vulnerability in Microsoft DirectShow Could Allow Remote Code Execution. This vulnerability should be considered high-risk as it allows for remote code execution through a browser using the Windows Media Player ActiveX control. In this blog post I provide a brief walk through of details of this issue and touch upon how it can be exploited in a reliable fashion.

This vulnerability manifests itself within the quartz.dll module located within the \Windows\System32 directory. This DLL is part of Microsoft's DirectShow multimedia framework and is responsible for parsing various media formats and handing data off to appropriate installable compressors and decompressors. Frequently, vulnerabilities in media formats exist within these installable compressors (see TPTI-09-01 and TPTI-09-02 for recent examples), however, in this case the problematic code is located within quartz itself. It should be noted that Quicktime does NOT need to be installed for this issue to be exposed.

Prior to Vista, DirectShow had support for parsing Apple's Quicktime format. This support was built upon DirectShow's COM-based architecture. DirectShow defines the IFilter interface that is used to implement filter graphs to render and perform miscellaneous operations on streams of media data.

When attempting to open a media file, quartz loops through different media types (defined as AM_MEDIA_TYPE structures, essentially GUIDs) and determines if the next node on the filter graph can handle the input stream's media type, negotiated via objects called Pins (see Mark Dowd and John McDonald's Media Frenzy presentation).

In practice, the Pin negotiation can be seen in a debugging session as a series of calls similar to this:

02d6f770 74837a7f quartz!CBaseMSRFilter::NotifyInputConnected+0x50

02d6f784 748340b2 quartz!CBaseMSRInPin::CompleteConnect+0x3a

02d6f79c 7483df8d quartz!CBasePin::ReceiveConnection+0xc2

02d6f7bc 7483e7d7 quartz!CBasePin::AttemptConnection+0x54

loop here until a successful connection

02d6f7e0 7483e36f quartz!CBasePin::TryMediaTypes+0x64

02d6f80c 7483e2f9 quartz!CBasePin::AgreeMediaType+0x73

02d6f824 7483e048 quartz!CBasePin::Connect+0x55

In the case of this QuickTime DirectShow issue, when provided with a malicious file quartz determines the media type can be handled by the CQT class. We know that video data is handled in streams. Taking a look at the symbols contained within quartz that contains references to CQT, we see another interesting class called CQTStream. Below is a listing of the functions with symbols for this class:

CQTStream::BuildMediaType(long,CMediaType *)

CQTStream::CQTStream(ushort *,long *,CQT *,ushort const *,int)

CQTStream::ConvertInternalToRT(__int64)

CQTStream::ConvertRTToInternal(__int64)

CQTStream::DecideBufferSize(IMemAllocator *,_AllocatorProperties *)

CQTStream::GetAvailable(__int64 *,__int64 *)

CQTStream::GetDuration(__int64 *)

CQTStream::GetEndOfChunk(long,long,long)

CQTStream::GetMaxSampleSize(void)

CQTStream::GetMediaType(int,CMediaType *)

CQTStream::GetStreamLength(void)

CQTStream::GetStreamStart(void)

CQTStream::IsFormatSupported(_GUID const * const)

CQTStream::MapByteOffsetToSample(long,long *)

CQTStream::MapSampleToChunk(long,long *,long *,SampleToChunk * *)

CQTStream::MapSampleToTime(long)

CQTStream::MapTimeToSample(long,long *)

CQTStream::OnActive(void)

CQTStream::RecordStartAndStop(__int64 *,__int64 *,double *,_GUID const * const)

CQTStream::RefTimeToSample(CRefTime)

CQTStream::SampleToRefTime(long)

CQTStream::UseDownstreamAllocator(void)

CQTStream::`vector deleting destructor'(uint)

CQTStream::~CQTStream(void)

We can see that the only functions here that take a MediaType as an argument are the BuildMediaType and GetMediaType functions. It's a safe bet to assume that they will be handling file data at a relatively lower level than some of the utility functions. Quickly disassembling GetMediaType shows that it is only 6 basic blocks and does nothing of interest to us.

Disassembling BuildMediaType shows more promise. Firstly, an interesting item to note, the presence of a stack cookie:

.text:748FB8B0 private: long __stdcall CQTStream::BuildMediaType(long, class CMediaType *) proc near

.text:748FB8B0

.text:748FB8B0

.text:748FB8B0

.text:748FB8B0   mov     edi, edi

.text:748FB8B2   push    ebp

.text:748FB8B3   mov     ebp, esp

.text:748FB8B5   sub     esp, 528h

.text:748FB8BB   mov     eax, ___security_cookie

.text:748FB8C0   mov     [ebp+stackCookie], eax

If a standard stack overflow were present in this function it might be a little bit more difficult to exploit. However, as we'll see this particular DirectShow issue is a more unique stack corruption vulnerability that will not be affected by the stack cookie mitigation.

A couple basic blocks into this function shows the first sign that it's parsing file data:

.text:748FB8EC loc_748FB8EC:

.text:748FB8EC   mov     eax, [ebx+1B8h]

.text:748FB8F2   cmp     eax, 'ediv'

.text:748FB8F7   jz      loc_748FBA9D

.text:748FBA9D loc_748FBA9D:

.text:748FBA9D   push    22

.text:748FBA9F   pop     ecx

.text:748FBAA0   lea     edi, [ebp+var_6C]

.text:748FBAA3   rep movsd

The 'vide' comparison here is a test for Apple's Quicktime image compression type. Following the successful branch we arrive at basic block that begins with a 22 byte seek, which, according to Apple's file format documentation, jumps over some extraneous structures and arrives at the very beginning of the ImageDescription ('stsd') atom.

This is where the vulnerability begins to manifest. Specifically, the next couple instructions are responsible for parsing the 'name' element of an ImageDescription structure. This field is a 32-character Pascal string, implemented as a 31 character string prefixed with a 1 byte length value. Herein lies the problem... if this length byte is larger than 31 characters an attacker can fool the code within quartz into writing a NULL byte beyond this string. The code responsible for this is shown below:

.text:748FBAA5   movsx   eax, [ebp+pascalStrLen] ; the string length prefix byte

.text:748FBAA9   mov     [ebp+eax+var_39], 0 ; attempted null terminate

So, this vulnerability allows a malicious media file to write a single NULL byte within 255 bytes in one direction of the stack variable var_39. Now comes the fun part, exploitation. Below is a WinDBG transcript demonstrating how this can be exploited:

0:017> bp quartz!CQTStream::BuildMediaType+0x1f5

Bp expression 'quartz!CQTStream::BuildMediaType+0x1f5' could not be resolved, adding deferred bp

0:017> g

Create thread 17:338

ModLoad: 76360000 76370000   C:\WINDOWS\system32\winsta.dll

ModLoad: 74810000 7497d000   C:\WINDOWS\System32\quartz.dll

ModLoad: 75f40000 75f51000   C:\WINDOWS\System32\devenum.dll

Breakpoint 0 hit

eax=65646976 ebx=01192bf0 ecx=00000000 edx=00000000 esi=01192b8e edi=01b9f08c

eip=748fbaa5 esp=01b9eb6c ebp=01b9f0a0 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

quartz!CQTStream::BuildMediaType+0x1f5:

748fbaa5 0fbe45c6        movsx   eax,byte ptr [ebp-3Ah]     ss:0023:01b9f066=40

The above line is showing the single length byte that comes directly from the file. Now, here is the NULL byte write which is attempting to terminate the Pascal string. The offset is stored in @eax and thus can cause the following memory write to seek past the string. At this point we can check the call stack to determine a good location to write the 0x00 byte. This is a contrived example as I have already chosen a location that is 0x40 bytes away from ebp-0x39, but for completeness the call stack follows.

0:017> k

ChildEBP RetAddr

01b9f0a0 748fc639 quartz!CQTStream::BuildMediaType+0x1f5

01b9f154 748387f0 quartz!CQT::CreateOutputPins+0x705

01b9f770 74837a7f quartz!CBaseMSRFilter::NotifyInputConnected+0x50

01b9f784 748340b2 quartz!CBaseMSRInPin::CompleteConnect+0x3a

01b9f79c 7483df8d quartz!CBasePin::ReceiveConnection+0xc2

01b9f7bc 7483e7d7 quartz!CBasePin::AttemptConnection+0x54

01b9f7e0 7483e36f quartz!CBasePin::TryMediaTypes+0x64

01b9f80c 7483e2f9 quartz!CBasePin::AgreeMediaType+0x73

01b9f824 7483e048 quartz!CBasePin::Connect+0x55

...

So, the quickest location to attempt an overwrite is the return address within the stack frame at 0x01b9f0a0. The return address is currently 0x748fc639. By changing a single byte in this, we can cause the process to return to address space that can be reached via a javascript heap fill (in the context of a browser). This makes for a simple exploit technique that can be made fairly reliable (except of course if we're dealing with a DEP-enabled process in which case a more advanced exploitation technique is required). So, let's see what happens when we overwrite a single byte of that return address.

0:017> t

eax=00000040 ebx=01192bf0 ecx=00000000 edx=00000000 esi=01192b8e edi=01b9f08c

eip=748fbaa9 esp=01b9eb6c ebp=01b9f0a0 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

quartz!CQTStream::BuildMediaType+0x1f9:

748fbaa9 c64405c700      mov     byte ptr [ebp+eax-39h],0   ss:0023:01b9f0a7=74

Here is the before:

0:017> dd 01b9f0a0 L2

01b9f0a0  01b9f154 748fc639

After the NULL write:

0:017> dd 01b9f0a0 L2

01b9f0a0  01b9f154 008fc639

So, now if we let the process go at this point it will return to 0x008fc639 which should not be mapped memory.

0:017> u 008fc639

<Unloaded_i.dll>+0x8fc638:

008fc639 ??              ???

                ^ Memory access error in 'u 008fc639'

0:017> g

(674.f0): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=00000000 ebx=01173e38 ecx=0000930b edx=00090608 esi=01192bf0 edi=01192dd0

eip=008fc639 esp=01b9f0b4 ebp=01b9f154 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246

<Unloaded_i.dll>+0x8fc638:

008fc639 ??              ???

0:018> !address @eip

    008c0000 : 008c6000 - 000fa000

                    Type     00020000 MEM_PRIVATE

                    State    00002000 MEM_RESERVE

                    Usage    RegionUsageHeap

                    Handle   008c0000

At this point it's game over, a heap spray can easily reach this address. However, exploit mitigation techniques such as DEP would prevent this method as the pages of memory would not have the execute bit set and thus this would throw an access violation even if code was present at that address. A more advanced exploit could use Alexander Sotirov and Mark Dowd's .NET trick to overwrite a different portion of the return address and return to a loaded module controlled by the attacker, but that is out of the scope of this post.

On a related note I just returned from Sao Paulo, Brazil where I spoke at the You Sh0t the Sheriff conference on the discovery and exploitation of vulnerabilities in 3rd party codecs as well as delving into the inner workings of DirectShow. The slides should be uploaded to the DVLabs Appearances page next week.

The YSTS event was very informative and I will be writing a blog post soon covering the presentations I had the pleasure of attending.


--
Aaron

 

{ Comments on this entry are closed }

Date: Thu, 8 Jan 2009 08:26:45 -0800 (PST)
From: Rob Lee
Reply-To: Rob Lee
Subject: Re: [GCFA] Compiling evidence boils down to a matter of time
To: Dave Hull
Cc: GCFA
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-496094974-1231432005=:13648"
Message-ID: <1401.13648.qm@web42107.mail.mud.yahoo.com>

--0-496094974-1231432005=:13648
Content-Type: text/plain; charset=us-ascii

Done. That takes care of Windows 7 and Window Server 2008. Can you verify it can adjust all four timestamps or just a few of them? We can then add that to our list of known default programs. Also, can you document how it is used and what traces are left in its use?

What type of beer do you like and what is the next SANS conference you will be at?

--Rob


______________________________________________________________________________________________





________________________________
From: Dave Hull
To: Rob Lee
Cc: GCFA
Sent: Thursday, January 8, 2009 11:11:17 AM
Subject: Re: [GCFA] [HTCC] Compiling evidence boils down to a matter of time

Interesting thread. Windows 7 and Windows Server 2008 ship with
Powershell. Powershell can be used to modify timestamps. See this
entry on my blog for more info:

http://trustedsignal.blogspot.com/search/label/timestamps

Where's my six pack? ;)

--
Dave Hull
Trusted Signal
CISSP, GCFA, GCIH, GREM, SSP-MPA, CHFI
Public key: http://trustedsignal.com/pubkey.txt
Fingerprint: 4B2B F3AD A9C2 B4E1 CBDF B86F D360 D00F C18D C71B

"Great minds discuss ideas; Average minds discuss events; Small minds
discuss people." -- Eleanor Roosevelt

--0-496094974-1231432005=:13648

{ Comments on this entry are closed }

Today the OWASP Security Spending Benchmarks Project Report for Q2 was published.

This project measures security spending in the development process. This quarter we focused on cloud computing. We were trying to measure how much use companies are making of cloud computing, how this affects spending, and how they are dealing with related legal and business issues.

We are lucky to have some great security folks volunteering their time on this OWASP project - Jeremiah Grossman, Rich Mogull, Dan Cornell, Bob West, and others have all provided valuable feedback and support. We were also very fortunate to have organizations like the Open Group and the Computer Security Institute (CSI) join our project over the last quarter. They join organizations such as eema, Teletrust and companies such as nCircle, Cenzic, Fortify and others that have been actively contributing to this effort. A full list of partners can be found on the project website.

Cloud computing gets some people's eyes rolling because it sounds like a marketing gimmick or meaningless term. But whatever you want to call it, infrastructure, platforms, and software are resources that are increasingly being outsourced or externally hosted. This has enormous security implications because it undermines the traditional notions of ownership and management that security has been based on in the past.

Here are the key findings in the OWASP Security Spending Benchmarks Q2 report:

THE OWASP SSB Q2 SURVEY RESULTS:

1. Software-as-a-Service is in much greater use than Infrastructure-as-a-Service or Platform-as-a-Service. Over half of respondents make moderate or significant use of SaaS. Less than a quarter of all respondents make any use of either IaaS or PaaS.

2. Security spending does not change significantly as a result of cloud computing. Respondents did not report significant spending changes in the areas of network security, third party security reviews, security personnel, or identity management.

3. Organizations are not doing their homework when it comes to cloud security. When engaging a cloud partner, only half of organizations inquire about common security-related issues, and only a third require documentation of security measures in place.

4. The risk of an undetected data breach is the greatest concern with using cloud computing, closely followed by the risk of a public data breach.

5. Compliance and standards requirements related to cloud computing are not well understood. Respondents report having the greatest understanding of PCI requirements relating to cloud computing and the least understanding of HIPAA cloud requirements.

SURPRISES AND NON-SURPRISES IN OUR SURVEY RESULTS...

1) The fact that SaaS is reported as the most prevalent of all cloud models is not surprising at all. Leveraging Platform-as-a-Service requires a level of expertise and sophistication many companies still do not have. And Infrastructure-as-a-Service has been dogged by performance issues and has yet to really supply an appropriate ROI model.

2) It is more perplexing that organizations do not report significant spending changes as a result of cloud computing. On the face of it, one would expect that cloud computing would result in lower expenses in a number of security areas, particularly network security. The fact that this has yet to occur may mean that organizations have been slow to adapt security budgets as a result of their cloud activities. Over time, both budgets and the role of security management will be increasingly focused on managing and auditing cloud relationships. Which brings us to number 3...

3) It is also somewhat surprising that organizations are not doing their homework when it comes to cloud computing. The survey found that only a third of organizations ask for the security policies of cloud partners. With all the talk of cloud security dangers, you would expect there to be heightened awareness and that companies would take the time to look into cloud partners' security narratives. That this has not been happening indicates that companies see cloud computing in the same vein as other outsourcing arrangements - the actual under-the-hood operations or security are not that important as long as the issues are contractually addressed. This approach may be more a result of necessity than choice, since for a small company with significant operations in the cloud it is hard to see how they could make any significant assessment of their cloud partner's security posture.

4) Data breaches are and will always remain the main fear factor driving the security industry. While compliance has always a bit fuzzy (especially when it comes to non-technical regulations, where there is a lot of wiggle room), the same cannot be said of a breach. You have either been breached or you haven't, which probably accounts for the greater concern survey respondents reported. It is interesting however that despite this very high level of concern with data breaches, organizations are still doing very little to vet cloud partners. Most organizations seem to have come to the conclusion that although there are many data security dangers related to cloud computing, there is not much they can do to mitigate this risk.

(5) Compliance is the issue that is really raining on the entire cloud computing parade. While PCI has fairly detailed supporting documentation to guide companies, other standards and regulations are much more vague so it is easy to see why people are confused. Regulators are still struggling to understand Web 1.0, so I do not expect we will be seeing much concrete guidance in this area in the near future.

MOVING FORWARD...

I gave a whole bunch of caveats the last time we published our survey results about why web surveys need to be taken with a healthy grain of salt. This still holds true for our cloud computing survey, and probably even more so because no one seems to agree on what cloud computing is. But even so there are some important take-aways from the data we collected.

The most significant warning sign in the survey results in my opinion is that companies are moving to the cloud without really inquiring about the security policies and posture of their cloud partners. And when they do ask about these issues, they rarely ask for documentation. This does not bode well for the future security of cloud computing. Although smaller companies rarely have the resources to truly assess the security of their cloud partner, asking for written documentation of security policies at least forces the cloud partner to maintain a security narrative they share with customers. As more customers inquire about security, this security narrative takes on an increasingly strategic role for the cloud partner.

You can read the full report here.

{ Comments on this entry are closed }

Well, it’s good to see that InfoSecToday is still alive and well. I’m still alive, and as far as being well, well you know how that goes… Lots of changes over the last year or so - Still married (the same one), still have a job (the same one), have two kids in college now (the same ones), but a lot less in the 401k. I’ve been through two different iPods, and am on my second Zune (a big one).

{ Comments on this entry are closed }

When I was 16 years old, my Dad decided he wanted to purchase a Ford Mustang 5.0. It was his first new car purchase since the 1967 Mustang he bought after high school. I of course insisted he get the GT with all the options. I drove to the dealer with him and watched as he haggled with the salesman. Having worked in the automobile sales and service industry for 20 years, he knew what he wanted and seemed to know what it should cost. The dealer offered him option packages and upgrades which my father promptly turned down. When I asked why, he said that the sports package and power windows were not going to make a muscle car perform better and it was just something that would break. As a result he purchased a stripped down LX that was several thousand dollars less expensive than the GT and was .3 seconds faster from 0-60 mph. He had the car for almost 15 years before a tractor trailer took it out.

I recently, realized how much that experience affected me. It’s been over 20 years since that visit to the dealership and I just realized how deeply the idea of simplicity has steered my decisions with technology. In my previous post entitled the The Risk of Complexity I wrote about the difficulties of securing complex technologies and mentioned the importance of the fundamentals of security. I wanted to expand on that thought here and outline some simple things that one should look for when evaluating technology solutions. Some fundamental features every solution should include are; reliability, detailed logging, ease of systems administration, complete and accessible documentation, and a proven support history. It is important to research the software provider’s track record on addressing functional bugs and security flaws.

It seems absurd, but many solution providers offering advanced technologies and features seem to fail terribly at basic functionality and stability. To summarize, it does not matter how sexy a security solution is if it fails open, crashes, or has unaddressed bugs in it. Moreover, if descriptive logs and documentation are not available and you cannot obtain an intelligent response from product support on an issue, then you have put the data you are assigned to protect at risk.

I recently had a conversation with the sales executive of a security solution on issues I have experienced with their product. His purposed solution was to purchase the new model with the extended warranty (also known as an upgrade with premium support). When I asked why I needed premium support to report an unpatched remote code execution vulnerability in a supported version, he attempted to sell me another solution his company offers.

So I wanted to offer this suggestion to those test driving solutions: The next time you are evaluating a product, ask some of questions regarding the aforementioned matters. Kick the tires and listen to the sound the door makes when you slam it. Test drive the product and make sure the suspension system is tight at high speeds. If Hyped Solution Inc. keeps pushing the limited edition report package or pie chart upgrade, then it may be time to drive up the street and find another dealer.

I would like to thank @Beaker for a recent tweet about his rental car and the recent blog post by @Jack_Daniel for jolting this memory out of my subconscious. Both individuals have remarkable ideas that they openly share with the security community and I fully recommend following their work.

{ Comments on this entry are closed }

This might seem just a tad bizarre, but I could really use your help.

I Built this diagram about a year ago.  I *think* I remember what the hell it was I was trying to visualize, but for the life of me…I can’t recall.

Seems a little odd to be asking you lot, but you’re pretty darn good at interpreting my madness.  Care to give it a whirl?  Give me the best explanation for my diagram below and win $25.  I’m good for it.  Ask the people who have won my whacky challenges before…payable via PayPal.

Thanks.

/Hoff

{ Comments on this entry are closed }

In honor of my friend Martin McKeay's trip to Kyoto for the annual FIRST conference, I present a variation on Abbot and Costello's Who's on First (Special thanks to the Baseball Almanac for having the original text on line)

Without further ado -

Who's in First

McKeay: Well Costello, I'm going to Kyoto. You know I've been given a job as official podcaster for FIRST for as long as I want it.

Costello: Look McKeay, if you're the podcaster, you must know all the members.

McKeay: I certainly do.

Costello: Well you know I've never met the guys. So you'll have to tell me their names, and then I'll know who's who.

McKeay: Oh, I'll tell you their names, but you know it seems to me they give these security professionals now-a-days very peculiar names.

Costello: You mean funny names?

McKeay: Strange names, pet names...like beaker...

Costello: His brother Daffy.

McKeay: what...

Costello: And their Dutch cousin.

McKeay: Dutch?

Costello: Kees.

McKeay: Kees Leune? That his real name. Well, let's see, we have on the board, Who's in first chair, What's in second, I Don't Know is in third...

Costello: That's what I want to find out.

McKeay: I say Who's in first, What's in second, I Don't Know's in third.

Costello: Are you the podcaster?

McKeay: Yes.

Costello: You gonna be the blogger too?

McKeay: Yes.

Costello: And you don't know the fellows' names?

McKeay: Well I should.

Costello: Well then who's in first?

McKeay: Yes.

Costello: I mean the fellow's name.

McKeay: Who.

Costello: The guy in first.

McKeay: Who.

Costello: The first board member.

McKeay: Who.

Costello: The guy leading...

McKeay: Who is in first!

Costello: I'm asking YOU who's in first.

McKeay: That's the man's name.

Costello: That's who's name?

McKeay: Yes.

Costello: Well go ahead and tell me.

McKeay: That's it.

Costello: That's who?

McKeay: Yes.

PAUSE

Costello: Look, you gotta FIRST board member?

McKeay: Certainly.

Costello: Who's leading first?

McKeay: That's right.

Costello: When you pay off the first board member every month, who gets the money?

McKeay: Every dollar of it.

Costello: All I'm trying to find out is the fellow's name on first board.

McKeay: Who.

Costello: The guy that gets...

McKeay: That's it.

Costello: Who gets the money...

McKeay: He does, every dollar. Sometimes his wife comes down and collects it.

Costello: Whose wife?

McKeay: Yes.

PAUSE

McKeay: What's wrong with that?

Costello: Look, all I wanna know is when you sign up the first board member, how does he sign his name?

McKeay: Who.

Costello: The guy.

McKeay: Who.

Costello: How does he sign...

McKeay: That's how he signs it.

Costello: Who?

McKeay: Yes.

PAUSE

Costello: All I'm trying to find out is what's the guy's name on first board.

McKeay: No. What is the second on the board.

Costello: I'm not asking you who's second.

McKeay: Who's in first.

Costello: One board member at a time!

McKeay: Well, don't change the board members around.

Costello: I'm not changing nobody!

McKeay: Take it easy, buddy.

Costello: I'm only asking you, who's the guy on first board?

McKeay: That's right.

Costello: Ok.

McKeay: All right.

PAUSE

Costello: What's the guy's name on first boards chair?

McKeay: No. What is in second.

Costello: I'm not asking you who's in second.

McKeay: Who's in first.

Costello: I don't know.

McKeay: He's in third, we're not talking about him.

Costello: Now how did I get on third chair?

McKeay: Why you mentioned his name.

Costello: If I mentioned the third baseman's name, who did I say is sitting third?

McKeay: No. Who's sitting first.

Costello: What's on first?

McKeay: What's in second.

Costello: I don't know.

McKeay: He's in third.

Costello: There I go, back on third again!

PAUSE

Costello: Would you just stay on third chair and don't go off it.

McKeay: All right, what do you want to know?

Costello: Now who's sitting in third chair?

McKeay: Why do you insist on putting Who on third chair?

Costello: What am I putting in third.

McKeay: No. What is in second.

Costello: You don't want who in second?

McKeay: Who is in first.

Costello: I don't know.

McKeay & Costello Together:Third base!

PAUSE

Costello: Look, you gotta other board members?

McKeay: Sure.

Costello: The secretary's name?

McKeay: Why.

Costello: I just thought I'd ask you.

McKeay: Well, I just thought I'd tell ya.

Costello: Then tell me who's the secretary.

McKeay: Who's in first.

Costello: I'm not... stay out of the chair! I want to know what's the guy's name as secretary?

McKeay: No, What is in second.

Costello: I'm not asking you who's in second.

McKeay: Who's in first!

Costello: I don't know.

McKeay & Costello Together: Third base!

PAUSE

Costello: The secretary's name?

McKeay: Why.

Costello: Because!

McKeay: Oh, he's sergent at arms.

PAUSE

Costello: Look, You gotta chairman on this boad?

McKeay: Sure.

Costello: The chairman's name?

McKeay: Tomorrow.

Costello: You don't want to tell me today?

McKeay: I'm telling you now.

Costello: Then go ahead.

McKeay: Tomorrow!

Costello: What time?

McKeay: What time what?

Costello: What time tomorrow are you gonna tell me who's chairman?

McKeay: Now listen. Who is not chairman.

Costello: I'll break your arm, you say who's in first! I want to know what's the chairman's name?

McKeay: What's in second.

Costello: I don't know.

McKeay & Costello Together: Third chair!

PAUSE

Costello: Gotta a archivist?

McKeay: Certainly.

Costello: The archivist's name?

McKeay: Today.

Costello: Today, and tomorrow's chairman.

McKeay: Now you've got it.

Costello: All we got is a couple of days on the board.

PAUSE

Costello: You know I'm a archivist too.

McKeay: So they tell me.

Costello: I get up to the table to do some fancy archiving, Tomorrow's chairman on my board and a heavy topic comes up. Now the heavy topic comes up, me, being a good archivist, I'm gonna look for input at first chair. So I pick up the topic and open it to who?

McKeay: Now that's the first thing you've said right.

Costello: I don't even know what I'm talking about!

PAUSE

McKeay: That's all you have to do.

Costello: Is to open the topic to first chair.

McKeay: Yes!

Costello: Now who's got it?

McKeay: Naturally.

PAUSE

Costello: Look, if I open the topic to first chair, somebody's gotta get it. Now who has it?

McKeay: Naturally.

Costello: Who?

McKeay: Naturally.

Costello: Naturally?

McKeay: Naturally.

Costello: So I pick up the topic and I open it to Naturally.

McKeay: No you don't, you open the topic to Who.

Costello: Naturally.

McKeay: That's different.

Costello: That's what I said.

McKeay: You're not saying it...

Costello: I opetn the topic to Naturally.

McKeay: You throw it to Who.

Costello: Naturally.

McKeay: That's it.

Costello: That's what I said!

McKeay: You ask me.

Costello: I open the topic to who?

McKeay: Naturally.

Costello: Now you ask me.

McKeay: You open the topic to Who?

Costello: Naturally.

McKeay: That's it.

Costello: Same as you! Same as YOU! I open the topic to who. Whoever it is drops the ball and the guy runs to second. Who picks up the ball and looks to What. What looks to I Don't Know. I Don't Know looks back to Tomorrow, Triple play. Another topic comes up and it to Because. Why? I don't know! He's on third and I don't give a darn!

McKeay: What?

Costello: I said I don't give a darn!

McKeay: Oh, that's our treasurer.



Hope you enjoyed
Just as a side note, I am not related Lou Costello.

James

{ Comments on this entry are closed }