There are quite a few tools readily known to the Android reversing community. The primary one is most likely smali/baksmali. It’s an open source tool which will decompile/compile an android dex format which is used by dalvik the native Android VM, into a format known as smali, which is very similar to an assembly language. A lot of people even like dex2jar, which further enhances the experience and takes a broken down apk, and pulls out the compiled dex classes. With dex2jar you can further that and attempt to get some readable jar files. If you wanted to make it even simpler you continue with that jar and use something like JD-GUI to read those jars back into native java code and be off running. For the lazy, there’s also the apktool which does most of the above for you in a simple one-stop-shop.

These are all great tools, but what else is out there? That’s what I’ll be covering in the next few articles. Today I’d like to point your attention to JEB (http://java-decompiler.com). I discovered this back in February when it made its first public release. At the time, I was knee deep in doing Android Application Security Assessments as part of our IPA process. I was still primarily using the tools mentioned above, so it was nice not only to find something different (it doesn’t use the open source smali as the decompiler), and it’s a nice all-in-one solution for exploring the code, as well as analyzing it.

JEB Interface

Some of the main features include the following, which I’ll go into more depth and why they add more benefit to this tool. The first is the Dalvik decompiler. From day one, I was immediately able to notice a difference between it and the smali decompiler. It uses some of the built-in properties and metadata of the DEX file and uses that to help interpret some of the code. I’ve also seen this change over the past couple months as they’ve improved it, or made other changes. It’s been optimized quite a few times. For me the code decompiled for JEB was broken down further and easier to read, even as a java programmer I’d prefer code to be in the simplest form when trying to analyze it, especially when dealing with unknown classes or libraries, not to mention any obfuscated code.

JEB has a few built in features which make analysis great as well allowing you to examine cross-references, rename methods, fields, classes and packages, navigate between code and data, add comments anywhere and even a notes tab. Putting this into practice is quite easy as well. I’d give a few examples but JEB’s video does a great job itself.

JEB not only gives you assembly and decompiled java views, it breaks down the entire apk, giving you access to all the assets, manifests, string lists and constants as well. Again, the other tools are capable of this, but you’re simply left with the basic file directories, in JEB you get a tab for each item listed out.

JEB also listens to its users with frequent updates, and added features or changes coming directly from the community. The JEB team listens and is active in development.

JEB Style Configuration

I think the only things I’ve noticed that I don’t like about JEB are mostly personal and nit-picky. First is because it’s much like an IDE in its layout, there’s no easy way to change the styling of the code views. Yes you can change it, within the options, but you have to go through every item individually and change them separately (comments, keyword, string, etc.). I did this once, but then accidentally overwrote those settings when I did an update. Which brings me to the second item; the update system requires you to download the latest version, which is archived with a password specific to you, you then unpack it, and do what you want from there. JEB does a check on load to tell you if there’s an update or not, but you still have to update it manually. I’ve spoken to the developers and this is something they’re working on but it’s not a priority. Lastly the decompiler omits any try/catch statements. It will leave a comment saying where they were, but it doesn’t actually leave any information that might have been needed. Specifically if an application spits out an error message in a catch block, that string isn’t there. Sometimes that string is useful for pinpointing certain items.

Otherwise JEB has been a great additional to my toolset; it’s one of the first things I go to if I need quick analysis of an APK. I’m just scratching the surface on this introduction to JEB, and will be doing a follow-up comparing it more deeply with some of its competitors and other tools I’ll be listing in these articles as well. Stay tuned!

Should Reasonably Have Known

The HIPAA Breach Notification Rule has an interesting turn of phrase: “should reasonably have known”.  A company is liable if they reasonably should have known about a breach.  So what is reasonable?  The latest 2013 rulemaking gives some guidance on that:  §164.404(a)(2) expands that to reasonably should have known by exercising reasonable diligence.  And then goes on to define it as “business care and prudence expected from a person seeking to satisfy a legal requirement under similar circumstances”.  Further adding that as soon as a workforce member or other agent has knowledge or should have had knowledge of the breach, the clock on notification starts.

So, you’ve got some relatively vague definitions of what’s reasonable, and as soon as someone at your company knew, or should “reasonably have known” about a breach, the clock starts on the notification timeline.   Who makes the decision on what is reasonable?  The HHS official looking into the breach.

There are some guidelines that can help determine what “reasonably should have known” might mean.  Most legal dictionaries define reasonable as “just, rational, appropriate, ordinary or usual in the circumstances.”  That’s still pretty vague, but it gives more of an idea of what reasonable means in this context: if most folks are doing it, you probably should too – or at least consider it.

When used in the context of  “should reasonably have known” in HIPAA, it is necessary to examine what others in your industry are doing as far as training, logging and review, and incident monitoring goes.  Evaluate what they are doing, determine if it’s “reasonable” for you to do the same, and if so, implement it.

Training

Why do you need to worry about training for learning about a breach?  The breach notification time line starts when any workforce member or agent should reasonably have known about a breach. Therefore, every person in your organization that is a workforce member (employee) or acting as an agent for the organization must know to notify those responsible for incident management within a specific time frame.  The incident management team needs to know right away about anything that might be a breach as required by §164.308(a)(5). Then that team can investigate and determine if it is actually a breach, and if it requires a response.

The only way to educate the entire workforce is via training. Putting it into a policy is a good idea, but that doesn’t mean that all employees will follow that policy.  Training doesn’t guarantee that either, but if you communicate the importance of your employees notifying the incident management team (or their manager, etc), you’re likely to get higher compliance from your employees.  And this training needs to include any agents working for you as well – independent contractors, business associates that may be agents, etc.

Logging and Review

As security experts, we’ve been telling folks to log security events where possible and review them on some schedule that makes sense for them for a long time.  Manual log review is one of the “low tech” ways to detect an incident – and relatively low cost.  As an auditor, I would expect to see logging turned on and periodic reviews of those logs.  It’s a required component of §164.312(b), so you’d better have logging and review of at least systems involved with PHI.  It could even be argued that you want logging and review on all systems and devices.  You may have attackers on your network, but they haven’t been playing around with your PHI systems – yet.  Having logging enabled on all of your systems may give you a “heads up” that gives you time to avoid a breach of PHI.  One thing you want to ensure is that the folks reviewing the logs are trained on that particular system, device or application as well as what is “normal” for your systems.  You want someone reviewing the logs that knows whether something is normal or not, and can filter out “false positives” that are common in logs.  And from an audit perspective – document everything!  Document your policies, document every time a log is reviewed, and document any communication about log configuration or log review.

Incident monitoring

Incident monitoring is a broad topic, but basically means the team, processes and procedures for discovering an incident (aka a potential breach).  There are a lot of things that go into incident monitoring, and this topic is where the “should reasonably have known” phrase leaves a lot open for interpretation.  Logging and review are definitely part of the incident monitoring processes, but many other things can be as well.  You can pay for a SELM or SIEM system or service, or you can do it manually yourself.  There are pros and cons to both ways.  The biggest con to a commercial SELM and SIEM systems is the cost.  They can be expensive!  When it comes to whether you “should reasonably have known” though, are you required to have an SELM or SIEM just because many of your peers do?  Ultimately the auditor or investigator will make that determination. However, you can document your research and decisions to make the case that your decisions are reasonable. Back it up with your methods of determining if a breach occurred, even your methods don’t require the latest, most expensive tools.

Conclusion

“Should reasonably have known” is a vague term, with limited guidance on what it means.  Ultimately, the auditor or investigator will make the determination.  To help you meet the Breach Notification Rule requirements, we suggest you look at your peers in the same industry, and seriously consider the same technologies and tools they are using.  Consider the benefits of those technologies and tools, and consider the cost to you – both in terms of the technology or tool, and in terms of fines for a breach.  Document your risk assessment process, and your decisions – whatever they are!  While HIPAA’s minimum penalty for willful neglect is $50,000, that still might not justify the cost for a SELM or SIEM system to protect PHI - unless you need it for another reason.  Whatever your decision, it is important to implement incident detection  and response mechanisms, whether automated or manual.

This article has been cross-posted from the Gemini Security Solutions website.

This article describes the HIPAA contingency planning and security incident response requirements. The relevant subsections of the HIPAA law are §164.308(a)(6) and §164.308(a)(7). 

HIPAA contingency planning is a term used broadly to cover security incident response procedures and contingency planning for emergency situations that may compromise protected health information. HIPAA contingency planning is one of the administrative safeguards that a covered entity must employ. The audit requirements for HIPAA contingency planning is covered in a separate post.

HIPAA Security Incident Procedures

“Implement policies and procedures to address security incidents.” [§164.308(a)(6)]

A covered entity is required to be able to identify, mitigate and respond to security incidents in a timely and reasonable fashion. The procedure for responding to security incidents should be formally documented, and each incident response event should also be fully documented, including the corrective action taken and the outcome of the incident.

This implementation specification is required.

HIPAA Contingency Planning

“Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information.” [§164.308(a)(7)]

A covered entity must implement contingency plans to ensure that electronic protected health information is kept secure (but remains available to those with appropriate authorization) even in the event of an emergency. Such an emergency can be any event that disrupts the normal operational state of the organization, such as power outages, fires, floods, etc. Five main areas of contingency planning, listed below, must be addressed in order to be HIPAA compliant.

Data Backup Plan

A covered entity must have established procedures for creating and maintaining backups of any electronic protected health information. These backups must be exact copies, and must be retrievable at any time, but they also must be kept secure from unauthorized access.

This implementation specification is required.

Disaster Recovery Plan

There must be an established and implemented procedure for restoring lost data in the event of a disaster recovery scenario. This goes hand-in-hand with the previous requirement for data backup planning. When a disaster event has passed, the covered entity must possess the ability for an authorized user to retrieve and restore an exact backup of all electronic protected health information.

This implementation specification is required.

Emergency Mode Operation Plan

In addition to backup and recovery procedures, a covered entity must also establish and implement procedures that allow critical operations that secure electronic protected  health information to continue during emergency conditions. Examples of such procedures could include providing backup power to facilities that house protected health information, or maintaining a secondary offsite facility that provides redundant storage and processes.

This implementation specification is required.

Testing and Revision Procedures

Contingency plans must be periodically tested and revised based on changing conditions and requirements. A covered entity must have a procedure for testing contingency plans that cover the security and availability of electronically protected health information.

This implementation specification is addressable, so if it is not applicable or reasonable for the entity to implement, there must be formal documentation explaining why, and what (if any) related controls are implemented instead.

Applications and Data Criticality Analysis

A covered entity’s contingency plans and actions should be prioritized based on the relative importance of the processes and data that they cover. For instance, high priority planning for the availability of electronic protected health information would include the use of back-up power to ensure that systems remain online in the case of electrical problems at a facility. The covered entity should assess and document which plans and actions are the most important and highest priorities when dealing with a disaster situation.

This implementation specification is addressable, so if it is not applicable or reasonable for the entity to implement, there must be formal documentation explaining why, and what (if any) related controls are implemented instead.

Changes in the 2013 HIPAA Update

No changes to the HIPAA contingency planning requirements were included in the 2013 HIPAA Omnibus Rule. However, as described in this article, business associates of covered entities are also liable for complying with the Security Rule. Therefore, these requirements also apply to business associates.

Summary

Incident response and contingency planning are important practices when managing protected health information. The ability to respond to and mitigate security events can help contain the damage in the case of a breach, while contingency planning ensures that unexpected events such as natural disasters only have minimal impact on the availability of data to those who are authorized to use it.

This article has been cross-posted from the Gemini Security Solutions website.

One of the lesser-known features of Windows 8 is the ability to sync a number of your settings for your system with your Microsoft account. This means you can sync your apps, your people (including Facebook, Twitter, Outlook, and LinkedIn contacts), and your photos so that they all appear no matter which Windows 8 system you log in to.

In addition to those settings, you can also sync your themes, favorites, history, and passwords to your Microsoft account. This means that your browser will look and behave the same as long as you are synchronized with the same Microsoft account.

These settings presented some concerns to me, because if my Microsoft account got hacked, some potentially sensitive information (passwords, bookmarks, and history) could end up in the wrong hands.

Fortunately, Microsoft has begun to roll out a long-awaited feature which improves the security of the Microsoft account: two factor authentication. I was excited to set this up for the account I use to synchronize my Windows 8 PC. Setting it up is easy. Go to https://account.live.com/ and after logging in, choose “Security Info” on the left side.

Click “Set up two-step verification” and begin the process. In my case, since I had already linked a phone number to my account (which previously saved my account), it offered me the possibility of calling me or texting me with a code in order to continue. Once I completed that process, my account was now configured to require a second factor of authentication whenever I connect from an unrecognized device.

To simplify things you can also use an authenticator app, either the Microsoft Authenticator for Windows Phone, or the Google Authenticator for iOS or Android. On the security settings page, click “Set Up” under the Authenticator App section of the page. You will receive a page like this:

Scan the barcode, and you will be able to generate login codes using the app. (Pro tip: if you have an authenticator account configured with same email address that is associated with your Microsoft account, you might want to rename the existing account in your authenticator app before scanning. Otherwise your account’s code might be overwritten.)

Now that my Microsoft Account is well and truly secure, now it’s time to configure the synchronization of my Windows 8 account and my Microsoft account. Hit the Windows button, and search for “Sync” in your settings. Choose “Sync Your Settings”.

Then, go ahead and turn on all the sync settings you want! Feel confident that your account settings are configured with a well-protected account.

Note: I am part of the Windows Champions program. As part of this program, I receive equipment and software from Microsoft to assist me in evaluating products and developing content.

This article describes the HIPAA information access management requirements for accessing electronic protected health information. The relevant subsection of the HIPAA law is §164.308(a)(4). 

Section §164.308 of the Health Insurance Portability and Accountability Act describes the administrative safeguards that a covered entity must employ. This article will explore section §164.308(a)(4), which deals with ensuring that appropriate authorization mechanisms are in place when electronic protected health information (ePHI) is accessed.

HIPAA Information Access Management

“Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part.” [§164.308(a)(4)]

A covered entity is responsible for isolating and guarding ePHI from unauthorized access. This section outlines the implementation requirements of a covered entity pertaining to protecting health information while still allowing access by those who need it for business purposes.

Isolating Health Care Clearinghouse Functions

This requirement is only applicable for health care clearinghouses which are part of a larger organization. In this case, the clearinghouse is responsible for implementing policies to protect ePHI from unauthorized access by the larger organization. An auditor will verify this by obtaining and examining formal policies to ensure that access controls exist and are sufficient, as well as verifying that these policies are approved and updated periodically.

This implementation specification is required for health care clearinghouses.

Access Authorization

Covered entities must implement formal policies and procedures for authorizing users before granting access to ePHI. Just authenticating workforce members to a system is not sufficient. Workforce members must also be granted access privileges through a documented process that strongly establishes the identity of the user and the need to access the ePHI. To verify this rule is implemented, an auditor will inspect these policies to ensure that they are sufficient for determining the need for access before granting it. The auditor will also determine if the policies are approved and updated on a periodic basis. Additionally, the auditor will verify that the entity’s IT department has the capability to enforce the access controls laid out in the policy through technical means wherever possible.

This implementation specification is addressable. If it is not applicable or reasonable for the entity to implement, there must be formal documentation explaining why, and what (if any) related controls are implemented instead.

Access Establishment and Modification

The covered entity must implement policies and procedures to establish, document, review, and modify user access rights to ensure that the appropriate level of access is granted at all times. This HIPAA information access management rule covers access to workstations, programs and other processes that may display, contain or process ePHI. To verify this rule is implemented, an auditor will inquire of management whether such policies exist, obtain and review formal documentation of these policies, and determine whether or not the policies are sufficient and periodically reviewed and updated.

This implementation specification is also addressable. (See above for explanation of addressable.)

Changes in the 2013 HIPAA Update

No changes to the HIPAA security awareness and training requirements were included in the 2013 HIPAA Omnibus Rule. However, as described in this article, business associates of covered entities are also liable for complying with the Security Rule. Therefore, these requirements also apply to business associates.

Summary

HIPAA information access management is designed to control access to electronic protected health information (ePHI) and is a crucial part of HIPAA compliance. By restricting access to PHI, the likelihood of a breach is reduced. Creating and maintaining formal policies and procedures to implement and routinely review HIPAA information access management rules and procedures will greatly increase the chances of passing a HIPAA audit, as well as diminishing the risk of a data breach.

This article has been cross-posted from the Gemini Security Solutions website.

On Saturday I was saved by a second factor of authentication.
 
I was playing the new SimCity game on my home computer in the basement, when my gaming session (surprisingly, it was playable that day) was abruptly terminated because my account had been logged on in a different location.
 
Seeing as how I only had one computer with the Origin software installed, I was surprised by this, so I restarted the game. It told me that I was logged on somewhere else, and if I logged on it would log me off the other location. “Sure, sure, whatever.”
 
A minute or two later, the same thing happens. Then I realize what’s going on.
 
I’ll admit, my Origin.com password was horrible. It was four characters long. That said, I was surprised that someone had bothered to capture it. The only game I have is the new SimCity, and it’s problematic as I alluded to in the earlier link.

So I again logged on, forced out the other user, and then went straight to the “change password” link. Here’s where things get fun. Origin’s password reset system requires you to not only have the current password, but also have the answer to your “secret question”. The problem is, my secret question was currently in cyrillic. (Looks like this isn’t uncommon.) So, I didn’t know the answer.

Luckily, the “I forgot my password so please send it to my email” link does not require the secret question to get involved. So I clicked that, got the email, and used the link in the email to reset my password. After that, I spent 30 minutes waiting for an EA technician on chat support to help me change the “secret question”. So now I feel like my account is safe.

Then I walked upstairs and was greeted by 6 voicemail messages on my cellphone. All of them were just strings of digits. This is one of the messages. It turns out, the attacker tried then to gain access to my email account by using the password I had used on Origin, and had kicked off some password reset attempts. Since I had configured my email to require a second factor of authentication (call to my cellphone) before allowing the password to be changed, my email account remained under my control – for now.

So the moral(s) of the story? Use a better password than I did, and make sure you set up second factors of authentication on all the accounts you can. As Smokey the Bear would say if he switched his focus to information security: “Only you can prevent account hijacking.”

This article describes the HIPAA workforce security requirements for restricting access to protected health information. The relevant subsection of the HIPAA law is §164.308(a)(3). 

Section §164.308 of the Health Insurance Portability and Accountability Act describes the required administrative safeguards for covered entities. This article explores section §164.308(a), which deals with ensuring that workforce members have appropriate (yet limited) access to protected health information.

HIPAA Workforce Security

“Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under paragraph (a)(4) of this section, and to prevent those workforce members who do not have access under paragraph (a)(4) of this section from obtaining access to electronic protected health information.” [§164.308(a)(3)]

This could be called the “need to know” rule. A covered entity is responsible for restricting access to protected health information to only those workforce members who require it.  However, all of the implementation specifications for this rule are deemed addressable. This means that the covered entity can assess whether or not the specification is a reasonable and appropriate safeguard. If it is not, then the covered entity must create formal documentation of why it is not applicable and what equivalent alternative measures are used to meet the standard.

Authorization and Supervision

Workforce members who access protected health information must be appropriately authorized and supervised. To verify this rule is implemented, an auditor will inquire whether policies that outline authorization levels and supervision requirements for access to protected health information exist. The auditor will also examine an organizational chart or other equivalent document to determine that lines of authority exist for enforcing these access rules.

Workforce Clearance Procedure

Anyone accessing protected health information must have a business need to do so and be qualified to handle that information. To verify this rule is implemented, an auditor will obtain and review formal documentation of the policies that enforce this standard, including what access levels have been established for access to protected health information, the procedures for granting access rights, and how workforce members are evaluated for the appropriate qualifications for access.

Termination Procedures

Access to protected health information must be revoked when it is no longer needed. Such situations could include an employee leaving the organization, being promoted, or being reassigned to a different project in which the protected health information access is no longer required. To verify this rule is implemented, an auditor will inquire whether there are policies in place to deal with termination of access to protected health information. There must also be policies for recovering or deactivating portable devices which may contain data (such as laptops and tablets), and devices which may grant access to data, such as cryptographic tokens and employee badges. Additionally, an auditor will obtain and review formal policy documents containing the procedures for terminating access to protected health information, as well as review evidence of monitoring to determine that access is terminated in a timely fashion.

Changes in the 2013 HIPAA Update

The language in the Termination Procedures section [§164.308(a)(3)(II)(C)] was updated to reflect that termination procedures must exist not only for employees, but all workforce members of a covered entity or a business associate. No other changes to the workforce security requirements appeared in the 2013 HIPAA Omnibus Rule.

Summary

Limiting access to protected health information (PHI) is a crucial part of HIPAA compliance. By restricting access to PHI, the likelihood of a breach is reduced. HIPAA workforce security can be increased through technical means as well as policies and education. Restricting access to PHI with formalized, documented policies and practices is a necessary step in becoming HIPAA compliant.

This article has been cross-posted from the Gemini Security Solutions website.

Last week at the RSA Conference I had the opportunity to attend the “Mobile Security Battle Royale“, featuring a great panel of experts on mobile phone security. Moderated by Zach Lanier, the panel featured Tiago Assumpção and Collin Mulliner paired off against Charlie Miller and Dino Dai Zovi (co-authors of iOS Hacker’s Handbook). 

As many great panels typically do, this panel featured no slides and no set talking points. Instead, Zach asked the panel some great questions to just get the ball rolling, and the panel started firing off great quotes left and right. I got busy live-tweeting the session and got (and re-tweeted) a few great quotes from many of the panel members which I have embedded below.

One of the recurring themes was “which is better”, comparing iOS to Android. BlackBerry/RIM got a few mentions as well since Tiago worked for RIM for a long time. The panelists did not come to any final conclusion, all the platforms have their benefits and their drawbacks. However, as a “battle royale”. there was a certain amount of desire from the moderator and the audience to declare a winner. My belief is that currently iOS is currently ahead, but the battle is close. The reason I’d tip my hat toward iOS at this time is for two reasons. First, it is slightly more expensive and difficult to get an app into the Apple App Store than Google Play, which makes things slightly more difficult for malware developers. Second, Apple iOS devices are generally running the latest version of the operating system, unlike the fractured Android ecosystem which has over half of the active devices running multiple major revisions behind.

Enjoy these quotes (paraphrased a little, I don’t have an eidetic memory) from this great panel discussion. I look forward to the rematch at next year’s conference.

“Apple disallowing downloaded code to be put into runtime was a hugely prescient decision.” – @dinodaizovi #RSAC

— Peter Hesse (@pmhesse) February 28, 2013

“Talking about antivirus for mobile, it just doesn’t make sense.” – @0xcharlie #RSAC

— Peter Hesse (@pmhesse) February 28, 2013

“We’ve proven that we can get to the moon. I personally don’t have the resources so the moon is safe from my attacks.” @dinodaizovi

— DennisF (@DennisF) February 28, 2013

Good point by @collinrm there are 3 parties needed to upgrade android: carrier, hw manufacturer, and Google, only 1 has incentive to upgrade

— Peter Hesse (@pmhesse) February 28, 2013

“The amount of web traffic that goes to phones is minuscule. So we might as well be talking about rhinoceros attacks.” @dinodaizovi #RSAC

— DennisF (@DennisF) February 28, 2013

“Jailbreaking should be legitimized, and the way to do it is compartmentalization.” – @coconuthaxor #RSAC

— Peter Hesse (@pmhesse) February 28, 2013

At the RSA Conference today, I attended an excellent panel discussion titled Y U NO HAZ METRICS? The speakers were David Mortman, Jack Jones, Alex Hutton, and Caroline Wong, and the panel was was moderated by John Johnson. The panel discussed risk management more than they discussed specific metrics, which was slightly different than what I expected. However, the panel surpassed my expectations.

A commenter towards the end of the session made an analogy which I thought was a good one. He said that risk management is like risotto. It has three basic ingredients, and you put them together and adjust the balance until it tastes good to you. In other words, no two risottos (or risk management programs) will ever be exactly the same. The commenter then brought up this follow-up concern: that we as an industry don’t even have an agreed-upon list of standard ingredients for our risk management risotto.

There are different risk management frameworks, which use and rely on different ingredients. However I think that Alex Hutton said it well:

“Governance without metrics is dogma. Governance with metrics is risk management.” -@alexhutton

— Peter Hesse (@pmhesse) February 27, 2013

Metrics are a critical part of a risk management system. Without metrics, it is impossible to tell whether the mitigation techniques and controls are working. In today’s world, you have an infinite number of threats and concerns to be worried about, and a fixed amount of time, money, and energy that can be spent. Without metrics, how can you determine where to spend that time, money, and energy? And how can you justify that the time, money, and energy was spent in the right place when you are served with a lawsuit because of a breach?

The last and possibly most important takeaway I’ll provide is this: useful metrics must relate to business value. Typically, risk management systems include metrics such as percentage of systems that are fully patched or amount of time it takes to apply a patch. These on their own are not useful metrics to a risk management system. They are only useful if they are tied back to things that are important to the business. So consider instead that the business impact of unpatched systems is that you could have a virus outbreak, and spend days restoring systems and handling the PR nightmare you’ve created. Or consider the business impact of having your e-commerce site down for three hours while you deploy patches.

This talk filled up and is being offered again today at 4:30 as an encore session here at the conference, so if you missed it, go check it out!

This morning, the 2013 RSA Conference truly got kicked off. Conference attendees gathered by the thousands into the main keynote hall at the Moscone Center in San Francisco. First up was a rousing set of Queen hits by a Queen tribute band. Unlike past years where a popular song is performed using primarily security-related lyrics, this year the music stayed mostly true to form. “We Will Rock You”, “We Are The Champions”, and “This Thing Called Love” were performed, and only a few lines at the very end of the last number were changed to security-related lyrics. The lead singer of the tribute band (The Queen Extravaganza) was quite good!

Art Coviello, Executive Chairman of RSA followed the band and took from the lyrics of the songs performed to make his points. He said that we, the people in the audience at the conference, are the champions… when champion is defined as an advocate, or a defender. However when champion is defined as the winner, he suggested that given the current state of threats that we can’t be defined as winners… yet. Coviello pointed to “big data” as a potential way for the security industry to get ahead of threats and win the battle against cyber crime.

Other keynote speeches were provided by Scott Charney from Microsoft, who described his optimism for the future of security, and Francis deSouza from Symantec, who described becoming more proactive against threats by combining corporate data with large-scale intelligence.

Then it was time for what is usually the highlight of the keynotes, at least for me: the Cryptographer’s panel. In this year’s panel, Ari Juels from RSA moderated a panel including Ron Rivest, Whitfield Diffie, Adi Shamir, and Dan Boneh. One of the topics that was discussed a lot was security and cryptography education. To that end, massive open online courses (MOOC) were mentioned, and Ron Rivest even recommended Dan Boneh’s online cryptography course. The panel mentioned some visionary topics, such as online voting (bad), mechanisms for making data exfiltration harder (good), and cryptography in a post-quantum-computing world. The sheer amount of brainpower on the stage at one time during that panel is always a joy to behold.

Tomorrow I will be attending two more keynotes that look very exciting; Vint Cerf will be talking about strong authentication and pseudonymity on the internet, and Jimmy Wales (founder of Wikipedia) will be discussing democracy and the internet.