In a week or two (or 3 or 4), I’ll be leaving on at least two months of maternity leave. Short/Long term leave is a pretty common scenario, whether for maternity leave, disability, or a sabbatical. People who have accounts and company knowledge are just “gone” for extended periods of time. Sometime, there’s advance notice, sometimes there’s not. What can you (or your company) do to make the transition easier from a security perspective?

Availability is one area of security – aka business continuity. If you know you’re leaving for an extended period of time, let your employer know as soon as reasonable. I know for maternity leave, many women and their partners wait until after the first trimester – there’s still 5-6 months to plan! Sometimes, in case of an accident (the proverbial “hit by a bus” scenario), there isn’t much advance notice. But as much as you can give, the better. Other than being polite, your employer has a chance to put a plan in place for your absence – heck, they might already have a plan they just need to implement. But it gives you a chance to transfer your knowledge to your colleagues (or possibly a temporary replacement), thereby continuing business.

Depending on the length of time you plan to be gone, you can do a few things to make your data more secure. Most maternity leave is at least 12 weeks in the US and much longer in other countries, that’s longer than the typical 90 day account deactivation/password reset timer. Depending on the specific arrangement with their employer, it may make sense to proactively deactivate these accounts and re-activate them upon returning to work – just make sure to mark the account as “do not delete” or something along those lines. If the employee will still be occasionally working, might as well just leave the account alone and make the employee change their password just like they normally would. If you’re the employee, it may be prudent to change your password before your leave (if you know when it starts), so that you get that maximum 90 day window.

If the employee suddenly goes on extended leave, such as a car accident, etc, then unless they plan on working from home, I would disable their accounts and re-enable them as the situation resolves itself. Maybe they’ll be able to work from home, maybe they won’t.

Unless the employee will be working from home, disable their VPN/remote access to reduce threats from outside. And if they have a company cell phone, it may be prudent to have them return that temporarily.

Communication – from both sides – is ultimately important. What if mom decides that she wants to become a stay at home mom? Letting your employer/employee know what’s going on will help the company’s data remain secure, by allowing the employer to make the right choices for the situation.

Here, for my leave, I’m working until the day I go into labor (who knows when that will be…), and so my exact date of starting leave is unknown. We’ve been training new employees to be able to handle all of my work while I’m gone, and I’ll be sort of available through e-mail to answer any questions that others can’t answer. I’ve changed my login password on all accounts, but since I plan on “working” part time, we’re not disabling my accounts so that I can still access my e-mail and remote access. I’ve put any passwords that my boss can’t readily change/access into a sealed envelope (encrypted e-mail in our case) in case he needs access for any reason, and we’ve let all of the clients I work with know that I’ll be gone at some point.

See you in a few months!

Here are 5 New Year Security Resolutions that may be useful to adopt in 2011.

1) Upgrade your password swagger

Several security incidents involving leaked passwords occurred in 2010. As long as passwords continue to be ubiquitous to single-factor security online, they will be huge targets for attackers. Beef up your account security by using different passwords for different accounts. Use a password manager to organize them, and use randomly generated passwords to make it hard for an attacker to guess their way in. Even starting a simple password rotation schedule for your own accounts can add some decent protection against password breaches.

2) Keep up with updates and patches

It’s not ideal to postpone things that are time-sensitive and intended to benefit you. One of the most critical moments for computer users is the time between the discovery of a vulnerability and the availability of a solution for it. In general, the sooner a fix is found and applied, the better.

3) Keep your ear to the streets

Sometimes, relying on official vendor updates isn’t enough. The computer security community can provide information on things that might not yet be acknowledged by companies or discussed in the public media. It can be a source for unofficial (but legitimate) workarounds/patches/fixes, or a source for reference information on the structure of a new botnet. Whether you get your news from RSS feeds, blogs, podcasts, mailing lists, or IRC channels, it’s important to have a way to stay informed.

4) Expand your knowledge on emerging technologies as vectors of attack

Computer security isn’t static because computer technology isn’t static. As we get new platforms, protocols, and programs, new attack vectors will present themselves. The first step to addressing these new vectors will be understanding how their underlying technology works.

5) Show other people how to be safer online

Not everyone finds computer security fascinating, but most people can benefit from it. It can’t hurt to teach someone how to spot scam emails, or how to
avoid drive-by malicious downloads.

Forget about everything that’s been made of password strength; it’s a red herring. True, you shouldn’t be using one common password across all sites, but that’s not a password selection issue. Should you pick good quality passwords that aren’t easily guessable? Absolutely. That being said, let’s forget about the rest of the rules, with perhaps the exception of length, and talk a bit about what actually happened with Gawker.

(more…)

A number of our employees are currently spending a fairly large amount of their time helping a customer with a task.  In a perfect world, this task would be completely unnecessary.  Suffice it to say that there is some maintenance that must be performed on a number of systems before the year is out, and they are having trouble getting responses from the system administrators who are responsible for the systems.

When we perform assessments, we often ask our customers about whether they have a configuration management database (CMDB) or something similar.  While CMDB systems may be useful for performing a physical inventory of your systems, that isn’t the real benefit. The real power of a CMDB comes in being able to track the current configuration, status, health, usage, and ownership of every system in the organization.  Let’s say a new patch is released; an up-to-date CMDB can help you understand what systems the patch applies to, whether they need to be patched and/or need prerequisite requirements fulfilled, what applications should be tested before and after the patch, and who the administrator(s) and owner(s) of the system are.

In this particular case, while there is a CMDB, it doesn’t do a good job of tracking the administrators and owners of their systems.  We are experiencing a huge gap in responsibility management.  While we may know of a system which needs maintenance, we don’t know who is responsible for its maintenance, and who is responsible for the information and applications which may be affected by the maintenance on that system.  In this organization, they are typically different people from different parts of the organization, who may not have even met.

Without understanding who is responsible for the system, the applications running on it, and the information stored within it, you are setting yourself up for problems. Well, you’re at least setting yourself up for many frantic emails and phone calls as deadlines draw near.

Recently I changed my personal firewall software. I was using the default Windows7 Pro firewall, which is fine for basic stuff, but I found a deal on one of my favorite security suites, so I went ahead and sprung for it. One main befuddlement people have with additional firewall software is the amount of nagging it often does when it’s first installed. You open your email client – popup – “program X is trying to communicate on port Y would you like to allow this?” You click yes, and move on. You open your instant messaging client and again – popup – “program X is trying to communicate on port Y would you like to allow this?” This can be annoying but this is usually the training mode of the software, it’s trying to learn what software you use, and it’s relying on you to make educated decisions on whether that software is really what you’re trying to run.

Usually firewalls only do this when they are initially installed and are in their “learning” modes. I usually keep it in “learning mode” for about a week to ensure I cover the plethora of software that I’d typically use. Then I go into lock down mode – blocking all other outbound and inbound traffic. Most people will only resort to a middle ground where most of the known ports are allowed, and others are not.

But this “learning” time period can also be beneficial. It will ask you whenever any program tries to communicate in/outbound – so if you start getting warnings when you’re not actively trying to run a program, then pay close attention to what program is trying to communicate. If it’s not a Microsoft service (windows) or some other service from a trusted source, then most likely it’s malware that’s been residing on your system for some time and you probably didn’t even know.

Most of this is beneficial to you home users, but it can also help those in the IT departments as well. It’s a good learning tool to help those just starting out to realize that there’s a lot more going on than you might expect. There are a lot of underlying communications that can occur especially in the corporate environment. So use these “learning” sessions to help educate yourself, for home and work life; and those in IT should be making notes of what is trying to communicate, and compare those with the known services that your company is running. Once you’ve determined all the proper services and software – opt to block all other in/outbound communications. You should document this in a policy and keep records of this. The last thing you want happening is not knowing what could potentially be coming or going from your networks.

One of the most common vulnerabilities in web applications is known as HTML injection or cross-site scripting, and one of the simplest ways of showing such a problem exists involves loading a JavaScript alert dialog. Those who understand the ramifications of such an issue know that it creates the potential for far more malicious activity, but the alert box is an easy demonstration that the application can be automatically manipulated.

Other vulnerability, though, may be more subtle and not as readily visualized. Take cross-site request forgery, for example. It’s easy to understand that there’s a problem when an application lets you manipulate the data of other users – the site should validate the account making requests before executing them. What may not be so obvious is that problems can still arise even when the application checks the account first. If no system exists for verifying that the account owner actually intended to perform a given action, it may be possible to hijack that user’s session and make requests without them knowing. The technical term for this behavior is cross-site request forgery.

(more…)

In talking to Peter last week, I asked him a question which we realized was pretty much impossible to answer:

How do you measure security strength?

That is, we know that an 8-character password with upper-case letters, lower-case letters, numbers, and special characters is definitely stronger than a 6-character password with only letters and numbers. But how much stronger is it?

Unfortunately, that’s incredibly hard to answer.

Of course, we know that there is no such thing as bulletproof security; if an attacker has sufficient time and resources, any security measure can be surmounted. Passwords can be broken, encryption can be cracked, etc. Given that the goal of security is to keep an attacker out, perhaps the most direct way to measure the effectiveness of security is, “How much effort will it take for the attacker to defeat it?”

This can be expressed in a fashion rather similar to programming complexity, using “Big O” or “asymptotic” notation. Which is useful because it communicates a key concept: multiple layers of poor security are not equal to one layer of good security. One might be inclined to think that, for example, requiring three weak password authentications is better than just one weak password authentication. But, while the difficulty in breaking one password is O(n), the difficulty in breaking three passwords is just O(3n) – which is, asymptotically, the same thing!

For real security improvements, the cost of defeating the security must be a higher order of complexity – it must be O(n log n), or O(n^2) or the like. That’s a real improvement over O(n). In the real world, this means adding levels of complexity to a password, requiring a hardware token, or adding in biometric identifiers.

But even expressing security in terms of complexity won’t really work: it doesn’t account for the myriad ways which attackers might use. Keeping passwords as an example, you may require strong passwords which truly are an order of magnitude harder to defeat than simple passwords… but if you’re not using good encryption for transmission, you’re no more secure. And even if you’re using good encryption, a wrench can still get the password (not that I advocate this method, of course, and especially not when my kneecaps might be involved!)

So, realizing that there are no easy fixes, and that attackers can be resourceful, how do you measure the level of security?

Well, so far the best idea I’ve seen has been to create a composite score based on your vulnerability to various attack vectors, giving weight depending on the expected likelihood of a given vector. Yes, that’s right: benchmarks.

And ultimately, you don’t want to get too hung up on the score. With benchmarks, you can usually manipulate to get whatever score you want. It’s just a number; the question is whether you’re secure. So use a metric, or pick a team that uses a metric, which you believe realistically reflects the threats you expect to see. And whatever the answer you get, the question is binary: “Am I secure enough?”

Here at Security Musings, we occasionally discuss some fairly technical topics. Like most speciallized subjects, there is a plethora of disorganized information, and occasional spatterings of highly organized resources on the Internet that help widen one’s knowledge and expertise in any given area.

One such spattering I recently came across is the online version of the Handbook of Applied Cryptography (not to be confused with the other book of similar appellation that is more-frequently used in college classes around the country).

Although it can get pretty nitty gritty at times with regard to the math and science involved in cryptography, sometimes that is exactly what you need to get the full picture and/or fill in the blanks that other resources gloss over in the interest of comprehensibility.

And best of all, the publishing company has released the chapters for free electronic distribution: http://www.cacr.math.uwaterloo.ca/hac/

Keep in mind, the last printing was in 2001, so some of the information may be a little aged. But if you’ve ever read any of our posts regarding public key encryption (Ch. 8, pdf), hash functions (Ch. 9, pdf), or digital signatures (Ch. 11, pdf), and wish we went a little further with the technical details, this just might satiate your thirst for knowledge.

Once upon a time, the Web was filled with static pages of text, hyperlinks, and the occasional image. Security problems existed even back then, but the pages themselves were generally innocuous. As the years went by, however, the Web became a platform for all sorts of communications and services. In time, the mild-mannered web page became a delivery mechanism for large-scale, dynamic applications. Even mobile browsers now include engines for loading powerful object-oriented programs. As the capabilities of websites expanded, the problem of HTML injection, or cross-site scripting (XSS), became a significant threat. Check any recent research on web-based threats, and you’ll find that this type of vulnerability is widespread online. And if the past few weeks are any indication, we can expect more trouble in the future.

HTML injection itself is hardly a recent issue, but current trends make it more common and more dangerous. In particular, the rise of user-generated content and “mashups” has led to far more data being shared across security contexts in real-time. One example made headlines last week after a few Twitter users discovered they could manipulate the site’s system for parsing links within a post to add custom HTML. Several tweets crafted to exploit this issue spread virally, as an action as simple as moving your mouse could trigger code that would post the same tweet under the victim’s account. Twitter’s entire product relies on user-generated content, but a simple filtering problem led to the rapid spread of XSS worms. Fortunately, none of these cases appeared to be that malicious.

In the realm of mashups, many sites are adding code to integrate with Facebook, providing users a single sign-on experience. A few websites have access to “instant personalization,” a feature that lets the sites identify Facebook users when they first visit rather than after clicking a login button. Soon after Facebook announced this program, a security researcher discovered that one of the partners, restaurant review hub Yelp, had an HTML injection vulnerability. With the addition of Facebook’s code, Yelp’s hole could be exploited to let an attacker automatically identify Facebook users as well. More recently, two new partners were added to the program: Rotten Tomatoes and Scribd. Soon after the announcements, similar problems were found in each of these sites. Ironically, Rotten Tomatoes’ pages were generally secure against HTML injection, but a third-party widget loaded by the site introduced a vulnerability.

HTML injection on one site threatens information and actions available to users of that site. But with so many websites sharing data between users and other companies now, one vulnerability may allow access to multiple services. And the problems don’t stop with the browser – injected code can try exploiting other issues that lead to compromising a user’s operating system. Meanwhile, the spread of mashups shows no signs of slowing. In fact, this past week Facebook’s COO Sheryl Sandberg predicted that within a few years, nearly all websites will automatically adapt to a visitor’s interests. Yet that sort of functionality requires identifying a visitor’s interests somehow, and Facebook’s instant personalization is one example of how that’s possible.

Securing a Web with so much data getting passed around is not an easy task. Douglas Crockford, a leader in the JavaScript community, has recently advocated that browser makers stop work on HTML5 and instead focus on building a more secure framework for handling scripts. Yet it’s more likely we’ll see a universally personalized Web before we see such functionality become mainstream, meaning web developers need to keep paying close attention to possible HTML injection issues. Preventing such vulnerabilities in an application would require more than a simple blog post, but fortunately many resources exist online, and the team at Gemini is ready to help you secure your code. In the meantime, I hope that the buzz about Twitter’s worms and problems with instantly personalized sites help draw more attention to HTML injection as the Web continues to expand. Hopefully future developers will learn from these stories and reduce their frequency in the future.

OAuth is a protocol that lets applications request data or privileges you have on a remote service without you having to provide your credentials for that service. A classic use case for this “valet key” system is contact import – you can let a site load your address book from Gmail without giving that site your actual Gmail password. Twitter recently required that any third-party applications using their API must authenticate using OAuth.

Twitter’s implementation is based on OAuth 1.0, which was finalized in April but has been in development for several years and is already widely supported. But work on a new version is now under way, and Facebook has already implemented one variety of the draft specification for applications that connect to their service. OAuth 2.0 currently defines specific flows, or client profiles, for handling authentication: Web Server, User-Agent, Native Application, and Autonomous. The first two are most commonly used for web applications, and implementations of the third may end up being quite similar.

The process for most clients involves three broad parts. (Note that “client” in this context refers to the application seeking access, not the person using the application.) The first involves user authentication. For a web-based service, this will often mean ensuring the identified user is currently logged in and then asking for their permission to enable access if they have not previously granted it. Second, the client has to authenticate. In other words, the client making the request has to prove it is the same application that the user granted permissions to in the first step. If both of these steps complete without error, the client is given means to access the protected resources, typically with a temporary code known as an access token.

The specific details of how these steps happen depend on the client profile used. Facebook’s standard Graph API authentication is an example of the Web Server flow. When first requiring access to private user data, a third-party application will forward the user’s browser to Facebook’s authorization server. The request includes a public code identifying the application and a URI under the application’s control. Facebook prompts the user for the permissions and (if they are granted) redirects the browser to the provided URI, along with an authorization code. The client then makes a request directly to Facebook which includes this authorization code and a secret code identifying the client. Facebook then sends back an access token, which is used to authenticate specific access requests for the duration of the session.

The User-Agent profile differs in that it relies on a user-agent’s same-origin policy rather than a client secret for authenticating the client. This process provides OAuth capabilities for JavaScript-based applications that do not have a server-side component and thus cannot ensure identifying codes are kept secret.

Simplicity was a major factor in creating OAuth 2.0, and thus several parts of OAuth 1.0, such as signatures and nonces, no longer apply. However, OAuth 2.0 requires transport-layer security of TLS 1.2 at minimum (as of draft 7) for the interface used to request and receive access tokens. The spec also recommends that secure channels be used for other parts of the process. In Facebook’s implementation, all server interfaces are accessed via HTTPS addresses.

From a security perspective, OAuth is a good step in that it discourages the anti-pattern of one application requesting a user password for another application. It can also protect users in other ways; for instance, if someone intercepted the authorization code for a Facebook application, they would not be able to use it for data access without also obtaining the application’s client secret. However, OAuth only addresses particular issues with third-party access and should not be considered a silver bullet for security. As an example, access by Facebook applications vulnerable to cross-site scripting may still be hijacked once the application has been authorized.

While OAuth 2.0 is still in draft status, Facebook’s deployment makes it in wide use already, and we’ll likely see many more implementations in the months to come. The description above should help you understand the basics of how OAuth 2.0 works, but if you’re interested in further details, check out the full spec and Facebook’s specific authentication guide.