Monday, December 16, 2013

Solaris Kernel Cryptographic Framework is FIPS-140 Validated!

Great news - we've been rewarded for years of hard work!

NIST has awarded FIPS 140-2 certificate #2060 to the Oracle Solaris Kernel Cryptographic Framework with SPARC T4 and SPARC T5 (Software-Hybrid), and FIPS 140-2 certificate #2061 for the Oracle Solaris Kernel Cryptographic Framework (Software) module.

This is a big piece of our validation puzzle for Solaris 11 cryptography.

The validation was based on Solaris 11.1 SRU3 and SRU5 on a variety of hardware platforms.


Tuesday, October 15, 2013

Celebrating Ada Lovelace Day at Oracle

Lovely infographic including Ada Lovelace Day tweets from many Oracle team members - Enjoy!


Monday, October 14, 2013

GHC13: A Man's Perspective - An Interesting View

I've seen men at the Grace Hopper Celebration of Women in Computing before, but I've never seen anything written by them after attendance.  This week I came across two outstanding blogs written by men about being a man at a female dominated event.

From Jamie Talbot, Is This What It's Like For Women At Every Conference?

From Owyn Richen, Grace Hopper 2013 - A Guy's Perspective:
"I was a little intimidated thinking about being among the minority at the conference, gender-wise, and it made me better understand how a woman might feel in our male-dominated industry. Once I got there, all I really felt was excitement about having the opportunity to learn from leaders in both the academic and industry sectors, who happen to be women."
Update: a third blog was sent my way by Matt Wallaert, Observations from the Land of Amazons:
"And honestly, having dramatically more women than men around actually made me relax too. There was no implicit competition, no being bothered by obnoxious crowds of guys crowded around the sexually attractive women and ignoring the less attractive ones."

These two [update: three] blogs from men that attended this year's GHC really put in perspective what it's like for nearly every woman at a male dominated conference, minus the fear of assault or having their opinions dismissed due to their gender.

These are really thought provoking and worth reading. Also, from these blogs, you get a real sense that this isn't just a "feel good networking event for women" (as I've heard it called by many who have a drastically incorrect impression of the event), but rather an outstanding technical conference that also helps you to grow your soft skills, inspires and raises your confidence as a person in tech.

GHC is one of the most inclusive conferences I've ever been to. You do not have to be a woman to attend, you don't even have to have a strong gender identity at all. The conference also provides FREE child care which really makes it possible for parent's to travel to such an event and not have to struggle to find child care in a strange city.

I missed this year's GHC (first time since 2007), because I was presenting at another conference the week before (ICMC) - but following the twitter feeds and blogs really helped me feel like I was attending virtually. Thank you, Online Communities Committee, for capturing your memories for me.

With Ada Lovelace Day this week, I have to say I continue to be inspired by the work that Anita Borg did to plant the seed to create this amazing community of women that is Systers, Anita Borg Institute for Women in Technology LinkedIn group (nearly 10K strong), Grace Hopper Celebration, Women of Vision Awards... her influence goes on and on and she inspires me nearly every day.

Any other blogs that I've missed? What are you thoughts?

This post syndicated from: Thoughts on security, beer, theater and biking!

Wednesday, October 2, 2013

Auditions: Join Me in the Lyric Victorian Carolers!

Who doesn't like Christmas Carols? If you do enjoy carols and would like to be a part of a very exciting Lyric opportunity to sing these lovely carols, we would love to have you join us. We are the Lyric Victorian Carolers and are looking for ensemble and quartet members to join this extremely successful caroling group for Lyric Theatre.

We will be singing from the 45+ carols in our repertoire from the tradition to some more contemporary holiday favorites. The events will be throughout the holiday season and range from private parties to various mall and large-scale events. There is no minimum number of engagements required and we will try to accommodate scheduling as best we  can. We realize the holiday time is a busy time for all but bringing the sights and sounds of a Victorian Christmas to our audience is really an extra special gift.

All auditions by appointment. Audition times: (Durations are 10 minutes)

Tuesday  October 8   6:30pm - 8:30pm
Wednesday  October 9  6:30pm - 8:30pm

We need all voice parts. We provide MP3s to help you learn your music.

This is a non-paid opportunity, as with all other Lyric productions. Auditions and rehearsals will be held at the Lyric Theatre Rehearsal Facility, 430 Martin Ave., Santa Clara. Further information about Lyric Theatre and directions to our facility are available on our website: www.lyrictheatre.org.

Please visit the sign up page or call 408-986-9090 and leave a message to schedule an audition appointment. Please allow 48 hours for a response.

Please prepare your favorite Christmas carol and come to the audition with your music, if needed. Please refrain from O Holy Night and Ave Maria for the auditions. We are an a cappella group so minimal accompaniment will be provided. Rehearsals will begin on Tuesday October 15 and run on Tuesday and Thursday nights. Conflict information will be solicited later.

If you aren't the performing type, but would like to see singers at  your church, community gathering, holiday party, wine tasting event, corporate party, etc, please contact us through our website: http://lyrictheatre.org/jl/outreach/caroling.html

Hope to see some of you there!

Tuesday, October 1, 2013

ICMC: Software in Silicon: Crypto Capable Processors: Slides

Our presentation went really well at the inaugural International Cryptographic Module Conference in Gaithersberg, Maryland last week. I co-presented with Dave Weaver (SPARC Architect) and Wajdi Feghali (Intel Architect).

As per popular demand, please find the slides online:

Thursday, September 26, 2013

ICMC: ISO/IEC 19790 Status and Supporting Documents

Presented by Randall Easter, NIST; and Miguel Bagnon, Epoche & Espri.

Mr. Bagnon started out by explaining the structure of ISO, the IEC and SC27 working group.  The ISO standards body looks at  creating market driven standards, getting input from all of the relevant stake holders.  The SC27 focuses on security and privacy opics across 5 working groups.  The SC27 has 48 voting member countries - from Algeria to Uruguay!  There are 19 other observing countries. You can see a very wide representation of continents, countries, cultures and languages.

The WG3 Mission is security evaluations, testing and specification. This covers how to apply the criteria, testing criteria, and administrative procedures in this area.

The process is open to the world (as you can see), drafts are sent out for review by the public before becoming a final international standard.  Please participate if you can, it's the only way to have your opinion counted.

Mr. Easter then dove into ISO 19790, and the related standards: ISO 24759 (test requirements for cryptographic modules), 18367 (algorithm and security mechanisms conformance testing), 17825 (testing methods for the mitigation of non-invasive attack classes against crypto modules) and 30104 (physical security attacks, mitigation techniques and security requirements).

ISO 19790 was first published in 2006 and it was technically equivalent to FIPS 140-2, plus an additional requirements for mitigation of attacks for Level 4.  This standard has been adopted internationally and is being used around the world.

What Mr. Easter had been hoping would happen was that ISO 19790 and FIPS 140-3 would closely track each other, with ISO 19790 picking up all of the changes from FIPS 140-3.  FIPS 140-3 was so delayed, though, that ISO 19790 began to develop independently.

Mr. Easter noticed that there were no validation labs participating in the ISO standard, so he got permission to circulate the draft amongst the labs and to incorporate their comments, as he's the editor of the document.

This document has been adopted by ANSI as a US standard now as well.

At this time, it is not officially recognized by NIST and the US Government.

This is very frustrating to many vendors and labs, because FIPS 140-2 was published in 2001 and it is quite stale (hence the 170 page Implementation Guidance). Technology is changing, the original language in FIPS 140-2 wasn't clear to all, and there seems to be a way out - if only NIST would adopt it.

Until that happens, vendors are stuck implementing to FIPS 140-2.

How can you change this? Call up your NIST representative or friendly CSEC contact and ask for this.

This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Key Management Overview

Presenters: Allen Roginsky and Kim Schaffer, NIST.

Key Establishment Methods



Key Establishment Methods in FIS 140-2 cover key agreement, key transport (including encapsulation and wrapping), key generation, key entry (manual, electronic, unprotected media), and key derivation.

The best method to make sure you do this right is to comply with SP 800-56A (CAVP KAS certificate required).

You can also use SP 800-56B, which is vendor affirmed right now. SP 800-56B is IFC based and key confirmation is highly desirable.

Or, you can use non-approved methods that rely on approved validated algorithm components. The shared secret is still computed per SP 800-56A with a CVL certificate. The kdf (key derivation function) then would be aproved (with a CVL certificate) per SP 800-56B and 80-56C.  There was a new version of SP 800-56A released in May 2013 that should help alleviate some of this convoluted cross referencing, and clarify many questions people have had over the last few years.

OR...you can even use non-approved, but allowed implementations.  That is, if your key strengths are consistent with SP 800-131A transition requirements.

Key Transport Modes

Key transport modes can be confusing as well.  Key encapsulation is where keying material is encrypted using asymmetric (public key) algorithm.  Key Wrapping, though, is where the keying material is encrypted suing symmetric algorithms. Both commonly provide integrity checks.

Approved methods would be an approved IFC based key encapsulation scheme as in SP 800-56B, key wrapping schemes (AES or 3DES based) as per PS 80038F, AES based authentication encryption m odes permitted in SP 800-38F, or as per SP 800-56A, a DLC-based key agreement scheme together with a key wrapping algorithm.

Any key encapsulation scheme employing an IFC based methodology that uses key lengths specified in SP 800-131A as acceptable or (through 2013) deprecated.   When AES or 3DES are used for wrapping, a CAVP validation of the algorithm is required.

Key Generation Methods

People often mistakenly believe that because they are using a good RNG, that they must be doing the right thing for key generation... not always the case!  You still need to follow SP 800-133 and IG 7.8 (Implementation Guidance).

The vendor needs to identify the method used and account for the resulting length and strength of the generated keys. This is about the generation of a symmetric algorithm key or a seed for generating an asymmetric algorithm key; the the generation of an asymmetric algorithm domain parameters and RSA keys.  See IG 7.8 and the future versioin of SP 800-90A.

You can use SP 800-132 for password-based key generation for storage applications only.

Key Entry

Implementation Guidance (IG) 7.7 provides examples explaining the FIPS 140-2 requirements. Key entry/output via the GPC internal path is generally N/A.  Key establishment over the unprotected media requires protection.  Split knowledge entry for manually distributed keys at Levels 3 and .

Key Derivation

When you're deriving a key - it's coming from something else. If you're deriving from a shared secret (per SP 800-135rev1), that includes the following protocols and their key derivation function are included: IKE (versions 1 and 2) , TLS (1.0->1.2), ANSI X9.42 and X9.63, SSH, SRTP, SNMP and TPM.  You can also drive from other keys, which is covered by  SP 800-108 - which also includes IEEE 802.11i key derivation functions (IG 7.2).



 This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: The Upcoming Transition to New Algorithms and Key Sizes

Presented by Allen Roginsky, Kim Schaffer, NIST.

There are major things we need to be concerned about – we need to move from old, less secure algorithms to the new ones. This includes the transition to 112-bit strong crypto and closing certain loopholes in old standards

The algorithms will fall into the following classes:
  • Acceptable (no known risks of use)
  • Deprecated (you can use it, but you are accepting risk by doing so)
    • This is a temporary state
  • Restricted (deprecated and some additional restrictions apply) 
  • Legacy-Use (may only be usd to process already-protected information) 
  • Disallowed (may not be used at all)
And of course, these classifications can change at any time. As you all know, the crypto algorithm arena is ever changing.  I asked a question about the distinction between Legacy-Use and disallowed.  It seems to me that you might find some old data laying around that you’ll need to decrypt at a later date.  Mr. Roginsky noted that they didn’t really cover this when they did the DES transition, and you might be okay because decrypting is not really “protecting” data.

When we get to January 1, 2014, 112-bit strength is required.  Two-key 3DES is restricted through 2015. Digital signatures are deprecated though 2013 if they aren’t strong enough.   This is an example where you could continue to use them for verification under “Legacy-Use” when we reach 2014.

Non SP-800-90A RNGs are disallowed for use after 2015 – you won’t even be able to submit a test report after December 31, 2013 if you don’t have an SP-800-90A RNG.

There is a new document everyone will want to review: SP 800-38 – it explains the use of AES and 2Des for key wrapping.

SHA-224, 256, 384, 512 are all approved for all algorithms. SHA-1 is okay, expect for digital signature generation. There are other changes around MACs and key derivation.

We’ll also be transitioning from FIPS 186-2 to FIPS 186-3/4.  Conformane to 186-2 can be tested through 2013.  Already validated implementations will remain valid, subject to the key strength requirements.  Only certain functions (such as parameter validation, public key validation and signature verification) will be tested for 186-2 compliance after 2013.  What this really means is that some key sizes are gone” after 2013: RSA can only use 2048 and 3072 keys.

Make sure you also read Implementation Guidance (IG) 7.12: RSA signature keys need to be generated as in FIPS 186-3 or X9.31.

The deadlines are coming up – don’t delay!

 This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Reuse of Validation of Other Third Party Components in a 140-2 Cryptographic Module

Presented: Jonathan Smith, Senior Cryptographic Equipment Assessment Laboratory (CEAL) Tester, CygnaCom Solutions

What is component in this context?  An algorithm, 140-2 module, third party library, etc - not a hardware device.  There is more interest in this area, as more validations are occurring.  Requirements are not obvious in this area, and there isn't a lot of guidance to follow.

Let's say you want to reuse an algorithm that has its CAVP certificates - if you wan to leverage that validation, you have to make sure you are talking about the same Operational Environment (OS/processor for software) and that there is no change within the algorithm boundary when you embed it within a module.  CAVP boundaries are not as well defined as CMVP, but for all intents and purpose it is the compiled binary executable that contains the algorithm implementation.

When you're reusing someone else's algorithm, you will have a hard time to make sure all of the CMVP self-tests are all being run at the right time. You may not be able to reuse it with out rebuilding it.

Now you may want to use an entire validated module - first make sure you have the correct validated version.  If you can use it completely unchanged, you will have to reference the other module's certificate.  One note, if the embedded module is Level 2, but your code only meets Level 1 criteria - the composite module could not be evaluated higher than Level 1. Now, the inverse is not necessarily true - you might be embedding a Level 1 module, but your different use cases may allow you to get a higher level for the composite module.

To reuse this module, again, you need to have an unchanged operational environment the same as trying to reuse an algorithm.  The new module boundary must include the entire boundary of the included module. You'll need to have a consistent error state - you cannot allow one part of the composite module to enter an error state while the rest of the system continues serving crypto.

Your documentation can quite frequently reference the embedded module's documentation, leaving certain tasks up to the embedded module.  Make sure the new capabilities of the composite module are documented.

A question came up about using multiple vendor's modules together, where they each have their own validation certificate.  Mr. Easter (CMVP) recommended we read Implementation Guidance (IG) 7.7 for detailed advice on this concept.

There was a question about if the embedded module was validated before new IG came out - what then?  As long as the embedded module meets SP800-31A, then the old certificate fully applies and you will not have to bring it up to the new IG.

This post syndicated from: Thoughts on security, beer, theater and biking!

Wednesday, September 25, 2013

ICMC: FIPS and FUD


Ray Potter, CEO, Safelogic.

Mr. Potter has seen lots of vendors jumping into the FIPS-140 bandwagon when they see another vendor claiming FIPS-140 certification, without understanding what that meant.  That other vendor may have simply gotten an algorithm certificate for just one algorithm, for example.

FIPS-140 is important - it provides a measure of confidence and a measure of trust.  A third party is validating your claims.  FIPS-140 is open and everyone in the world can read the standard and the IG and implement based on these and understand what it means to be validated. Most importantly, FIPS-140 is required by the US Government and desired by other industries (medical/financial/etc).

Having this validation shows that you've correctly implemented your algorithms and you are offering secure algorithms.

See claims like the module has been "designed for compliance to FIPS 140-2", or "it will be submitted" or "a third party has verified this" or "we have an algorithm certificate" or "we have implemented all of the requirements for FIPS-140" - none of these is truly FIPS-140-2 validated.

Once you have a certificate in hand from the CMVP, then you're validated.

But even when the vendor has done the right thing for some products, sales can just get this wrong - too eager to tell the customer that everything is then validated.

So, Mr. Potter has encountered honest mistakes, but he's also seen sales/vendors outright lie about this, because it simply takes too long and is too expensive to do this.  Why do this? Make the sale - hope your in process evaluation completes before the sale.

Issues that exacerbate the situation: unpredictable CMVP queues, new Implementation Guidance (IG) that is sometimes retroactive, and uneven application across the government.  Some government agencies may accept different phases (in validation) - where others require a certificate in hand.

Vendors get frustrated when they are in the queue for months, then get some retroactive IG that requires code changes - they don't see this as worth the effort.

We can help: educate your customers on the value of FIPS-140 validations and what it really means to be validated, only use validated modules and follow strict guidelines for claims.

There are some people that will take another FIPS-140 validated implementation, repackage it and get their own certificate for the same underlying module but with their name as the vendor on the cert.

I asked about why some vendors are doing validations of their crypto consumers, when they've already got a validation for the underlying consumer.  Mr. Potter noted that some people might do this because they need to cover the key management aspects that the consumer is doing that weren't covered in the other evaluation, or that the consumer may actually have some if it's own internal crypto in addition to what they are getting from the underlying module, or that they simply are trying to make a very important customer happy.

This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Understanding the FIPS Government Crypto Regulations for 2014

 Presented by Edwards Morris, co-founder Gossamer Security Solutions.

Looking forward to what new regulations are going to mean for older algorithms and the protocols that use them, right away there seems like there may be work for us to do.

Security strength of various algorithms are not straightforward to calculate, as it's based on how it's used and how big the key is, etc.

In May 19, 2005, DES is being sunset, because it has less than 80-bits of security.  Because this sunset applies to the bits of security, DH and RSA with key sizes smaller than 1024-bits are included.

Originally the DES transition gave people two years to migrate to AES or 3DES.

As a part of this, NIST released SP 800-57, which included recommendations for key management.

This was harder than anticipated, due to lack of standards, available 140-2 approved products and the sheer size of deployments - so then NIST 800-131A was born.

NIST 800-131A includes more details on the transitions, terminology and dates.  Some 80-bit crypto will be deprecated in 2013 and others in 2015.

The devil is in the details, of course,  SP 800-131A refers to SP800131B, which is in draft and ultimately because FIPS-140-2 Implementation Guidance.  Digging into all of these requirements, how can you tell if TLS can still be used?

Mr. Morris dug into  various protocols to help us interpret this standard.

IPsec

IPsec is made up of so many RFCs, so getting the big picture is not an easy task. It also has so many possible options.  SP 800-57 Pat 3 details this guidance.  Three IPsec protocols allow a choice of algorithms: IKE (for key exchange), ESP and AH.

You can avoid using IKE by using manual keying (acceptable 2014+, but what a pain to configure/deploy), IKEv1 (unacceptable in 2014) and  IKEv3 (acceptable 2014+, if configured correctly).

For encryption in IPsec, you'll be okay with ENCR_3DES (in CBC mode), ENCR_AES_CBC (CBC mode only), and a few others.  You'll be able to use SHA1 as an HMAC, but not alone for signatures (wow, does this get twisted).

Mr. Morris continued through what would be acceptable for Pseudo-random functions, Integrity, Diffie-Hellman group and Peer Authentication - too quickly for me to type all of those algorithms, but I will try to update this if I can get access to the slide deck.

It's not as simple as which algorithm you use, but again how you use it, which sized keys, etc.

IPsec is well positioned for this - as long as you configure it correctly.

TLS

TLS is not the same things SSL v3.0. TLS is equivalent to SSL v 3.1.  TLS 1.0 is acceptable. SSL, though, is not allowed by CMVP.  Since 1.0 is acceptable, that essentially means that TLS 1.1 and 1.2 are also acceptable, as long it's configured correctly (seeing a theme here?).  For example, if you use pre-shared keys in lieu of certificates, ensure the key is greater or equal to 112 bits.

You won't be able to use the following key exchanges: *_anon, SRP_*, KRB5. (though Mr. Morris hasn't dug through the Kerberos standards, yet, to see where they will be with these 2014 requirements.

SSH

This is not covered by SP 800-57, so this is harder to figure out if it's okay or not. There are problems when the RFCs require things that are no longer considered secure: Single DES are required to be implemented, but by having them available in your implementation - this will be a problem.

Recommendations

Look for documentation and configuration guides that can help there, or get independent evaluations of the software that you're deploying (companies like Gossamer will look at how you're using even opensource software like Apache, OpenSSL, OpenSSH, etc)

This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Building a Corporate-Wide Certification Program - Techniques that (might) work

Tammy Green, Security and Certification Architect at Blue Coat, came into what seemed like a simple task. She had had some Common Criteria experience when she joined Blue Coat, their product had previously been evaluated at FIPS-140-2 level 2, and they had already signed contracts with a consulting firm (Corsec) and lab.  Should've been easy, right?  Her new boss said it should take about a year and only 20% of her time.  Two and half full time years later... yikes.

One of the biggest problems was getting internal teams to work with her - even people involved in the previous validations didn't even want to talk to Ms. Green about it.

Nobody wanted to do this - they want to work on the new shiny features that they can sell, how does a process that takes 2 years (often not complete until after a product is EOL) help them?

It's hard to see the long term picture - you want to sell to the government, you need FIPS-140-2 validations.

Ms. Green didn't want to do this herself again afterwards. Instead of running away, she worked on setting up a certification team locally (her boss hiring a program manager helped to encourage it).

In addition to having the program manager, you need a certification architect.  You can't use the same architect as the product architect, because that person is busy designing shiny new features.

You need to work with the development team well in advance - fit your FIPS-140-2/Common Criteria schedule into their development schedule. You can't screw on the necessary tests and requirements as an afterthought, and you don't want to delay a schedule because requirements are dropped in at the end.

Target the right release: because FIPS-140-2 takes so long, you need to pick a release you plan on supporting for a long time.

Ms. Green found that after time... engineers stopped replying to her emails and answering her phone calls.  You need to identify key engineering resources to work with and their management needs to commit to those engineers dedicating 10-20% of their time to these validations.

Once you get this set up and have educated engineering, you'll find they'll reach out to you in advance - better timing!

Her team keeps track of what needs to be done: file bugs and track them.  You'd think the project manager for the product team would do this, but what she's found is that the bugs get reprioritized and reassigned to a future release.  Someone who understands validations needs to track these issues.

Ms. Green recommends that you create the security policy from existing documents: don't rely on engineers doing this. They simply don't understand what goes into this document or why it's important.  Instead, use engineering and QA to validate content.

It's important to convince QA continue to test FIPS mode and related features, as some customers may still want to run in FIPS mode (even though it wasn't validated) or that the release would be ready for validation if something went horribly wrong with the older release in validation.

Schedule time to prep. Ms. Green has 4-8 hour long meetings to make sure everyone understands what's important. Take time to prepare, make sure everyone knows what will be expected from the lab visit and have a test plan formalized in advance.  It's actually a lot of work to set up failures (the lab evaluators require that you demonstrate what happens when  a failure happens, even though you have to inject the failure to force it).  Debug builds, builds you know will fail, multiple test machines, platforms, etc.

To keep your team from killing you... or damaging morale, celebrate the milestones. Mention the progress in every status report, celebrate the milestones, do corporate wide announcements when you finish.

Do a post mortem to understand how this can be improved: give your engineering team a voice! Listen and take action based on what worked and didn't.

Update tools and features to make this easier next time: keywords to bugs and features, modifying product life-cycle, add questions related to FIPS to templates.

Suggestions/questions from the audience:
Make sales your best friend.  Validations/certifications are not fun, nobody does them for fun - you do this to make money.
Get the certification team involved as early as possible: from the very beginning - marketing design meetings.
Why don't you run your FIPS-140 mode tests all the time?  Time consuming, slower, not seen as a priority when there are no plans to validate.


This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Panel: How Can the Validation Queue for the CMVP be Improved

Fiona Pattinson, atsec information security, moderated a panel on CMVP queue lengths. Panelists: Michael Cooper, NIST; Steve Weymann, Infoguard; James McLaughlin, Gemalto; and Nithya Rahamadugu, Cygnacom.

Mr. McLauglin said the major issues for vendors with these queue lengths, because it impacts time to market. If you don't get your validation until after your product is obsolete, that can be incredibly frustrating. It's important to take schedule and time to market into consideration, which is impossible when you cannot anticipate how long you'll be sitting in the queue.

Mr. Weymann expressed how frustrating this is for a lab to be able to communicate to their customers what the expectations are and what to do when the implementation guidance is changed (or as CMVP would say: clarified) while you're in the queue - do you have to start over?

Mr. Cooper, CMVP, expressed that there is a resource limitation (this gets back to the 8 reviewers). But is simply adding resources enough?  They have grown in this area - used to only have 1 or 2 reviewers.  But does adding people resolve all of the issues?  Finding people with the correct training is difficult as well.  Hiring in the US Government can take 6-8 months, even if they do find the right person with the right background and right interest.

Mr. Weymann posits that perhaps there are ways that could better use our existing resources.  Labs could help out a lot more here, making sure things are in such good shape at submission that the work that CMVP has to do is easier.

Ms. Rahamadugu and Mr. Weymann suggested adding more automation into the CMVP process. Mr. Cooper noted that he has just now gotten the budget to hire someone to do some automation tasks, so hopefully that will result in improvements to pace.

A comment from the audience from a lab suggested automation of the generation of the certificate, once the vendor has passed validation.  Apparently this can sometimes be error prone, resulting in 1-2 more cycles of review.  Automation could help here.

Mr. Easter said they like to complete things in 1-2 rounds of questions to the vendor, and there are penalties (not specified) for more than 2 rounds.  Sometimes the answers to a seemingly benign question can actually bring up more questions, which will result further rounds.  Though, CMVP is quick to want to have a phone call to resolve "question loops".

Mr. Easter noted that he tries to give related reviews or technologies to one person. This often helps to speed up reviews, reducing the questions. On the other hand, that puts the area expertise in the hands of one person, so when they go on vacation - there can be delays.

Mr. Weymann noted that it seems that each lab seems to gather different information and presents it in different ways. For example, different ways of presenting which algorithms are presented, key methods, etc.

Concern from the audience about loss of expertise if anyone moves - could validators shadow each other to learn each other's area of expertise?  Or will that effectively limit the number of reviewers.
Vendors feel like they have to continually "train" the validators, and retrain every time - frustrating for vendors to do this seemingly over and over.

A suggestion from the audience: could labs review another lab's submissions before it went to CMVP?  This is difficult, due to all of the NDAs involved.  Also, a vendor may not want a lab working with a competitor to review their software.

Complicated indeed!

This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Impact FIPS 140-2: Implementation Guidance

Presenters: Kim Schaffer, Apostol Vassilev, and Jim Fox - all from NIST (CMVP).  The talk walked us through some of the most confusing/contentious recent updates to the Implementation Guidance document.

Implementation Guidance 9.10

Default Entry Points are well-known mechanisms for operator independent access to a crypto module. When an application loads, static default constructs, dynamically loaded libraries, etc - these access points are linked into the application.  When this default entry point is called, power on self tests must be called with out application or operator intervention.

This guidance exists in harmony with IG 9.5, which is regarding, essentially making sure there isn't a way for the module to skip power-on-self-tests.

Implementation Guidance 3.5

All services need to be documented in your security policy, even the non-approved ones.  Each service needs to be listed individually.  Some services can be documented externally, but those need to be publicly accessible (via URL or similar).

Operational Environment

This is defined as the OS and platform [Ed note: emphasis mine].

Today, processors are becoming nonstandard, so NIST can no longer just consider the OS alone and needs to reinvigorate the intent seen in the original document.  This gets more complicated with virtual machines (VMs) in the mix.

What they used to call GPC (general purpose processor), they are now referring to them as Special Processing Capability (SPC) because of the cryptography being added to the processors.

What do they mean by SPC?  extended calls to enhance cryptographic algorithm without full implementation.  Processors include Intel, Arm and SPARC.

If the module can demonstrate independence of SPC, then it won't necessarily be considered a hybrid implementation.  If the lab can show this, even though an implementation can leverage an SPC, they may still be considered a software or firmware implementation.

Questions

An audience member showed irritation that the new IG does not give time to implement (ie no grace period).  Mr. Randy Easter reiterated  that this is not a new requirement, but something that was formerly missed by the testing that the labs did. They want to nip these lapses in the bud and get people back on track.  Essentially correcting assumptions that CMVP was making about what the labs were testing. There are some changes/clarifications on this lack of grace period that were sent to the labs last night (not sure what's in that, but the labs all seem happy and are anxiously checking their mail).

Another question about why the very specific platform is required on the certificate. Mr. Easter noted that this is due to how dependent entropy is on the underlying platform - this becomes important to test and verify. This is a frustrating for Android developers.  Mr. Easter noted that most consumers, though, are happy to use the same module on slight variations of platforms (for example, different releases of Windows on slightly different laptop hardware - too many variations to actually test).

Mr. Schaffer noted that certificates do not need to go down to the patch level, unless the vendor requests it.


This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: CAVP/CMVP Status - What's Next?

We were lucky to have three panelists from NIST: Sharon Keller, Randall Easter, and Carolyn French, so we can hear about what they are doing straight from the horses mouth, as it were.  This is a rare opportunity for vendors to get to interact directly with members of these validation programs.

Ms. Keller, CAVP - NIST, explained a bit of history about this body. CMVP and CAVP used to be one group, but they were separated in 2003, as their tasks could easily be broken up.  As noted yesterday, the validations done by CAVP is much more black and white - you've either passed the test suite, or failed.  The CAVP has automated this as much as possible, which also contributes to the speed.

In addition to these validations, CAVP writes the tests, provides documentation and guidance and provides clarification, as needed.  They also keep an up to date webpage that lists algorithm implementations.

The rate of incoming validations seems to be nearly logarithmic growth!  Already this year, they've already issued more algorithm certificates than in all of 2012.  This year, they added a new tests for algorithms like SHA512/t.

Mr. Easter said that NIST had originally planned to do a follow-on conference to their 2003 conference in 2006, once FIPS-140-3 was finalized.... oops!

The original ISO/IEC 19790 (March 2006) was a copy of FIPS-140-2, the latest draft contains improvements that were hoped to be in FIPS-140-3.

Because FISMA requires that the US Government use validated crypto, these standards have become very important.

Vendors should make sure they reference the Implementation Guidance (IG). Mr. Easter noted that the IG, in their opinion, does not contain  any new "shalls", but merely clarification of existing requirements. Though, asking many vendors here, apparently the original document was so murky that these IGs seem like completely new requirements.  Now that FIPS-140-2 is so old (12 years now), the IG document is larger than the standard itself!  This can

There are actually only 8 full time reviewers for the CMVP, and those same reviewers also have to do bi-annual audits of the 22 international labs, write Implementation Guidance, etc - you can see why they are busy!

Reports from labs show the greatest areas of difficulty for conformance are key management, physical security, self-tests and RNGs.  Nearly 50% of the vendor implementations have non-conformance issues (8% are algorithm implementation conformance issues).

Mr. Easter apologized for the  queue and noted that this is not what they want either: they want the US Government to be able to get the latest software and hardware, too!

Currently, there are 200 reports in the queue that are actively being tracked and worked - again, 8 reviewers.  Is adding more reviewers the answer? How many people can they steal from the labs ;-)

What can you do to help?  Labs should make sure the reports are complete, in good shape, with all necessary elements..   Vendors should try to answer any questions as fast as possible.  Help close the loop, make the jobs of the reviewers simple.

Unfortunately,  work on FIPS-140-3 seems to have stalled in the group that evaluates new algorithms, and Mr. Easter would like NIST instead to adopt ISO19790 as FIPS-140-3 (it's ready to go: fleshed out, DTRs) - asking us to help pressure NIST to get this standard adopted.


This post syndicated from: Thoughts on security, beer, theater and biking!

ICMC: Welcome and Plenary Session

Congratulations to Program Chair Fiona Pattison, atsec information security, for putting together such an interesting program for this inaugural International Cryptographic Module Conference.   She has brought together an amazingly diverse mix of vendors, consultants, labs and NIST.  People from all over the world are here.

Our first keynote speaker is Charles H. Romine, Directory, Information Technology Laboratory, NIST. Mr. Romine started off his talk by noting how important integrity and security is to his organization.  Because of this, based on community feedback, they've reopened review of algorithms and other documents.  Being open and transparent is critical to his organization.

NIST is reliant on their industry partners for things like coming up with SHA3.  They are interested in knowing what is working for their testing programs and what is not working, hopefully they will get a lot of great feedback at this conference.

Because these validations are increasingly more valuable in the industry - demand for reviews have gone up significantly. How can NIST keep the quality of reviews up, while still meeting the demand? Mr. Romine is open for feedback from us all.

Our next keynote was Dr. Bertrand du Castel, Schlumbeger Fellow and Java Card Pioneer, titled "Do Cryptographic Modules have a Moat?"

Dr. du Castel asks, is the problem with cryptography simply key exchange? Or is it really a trust issue?  With things like bitcoin (now taxed in Germany) and paypal everywhere on the Internet - it should be obvious how important trust is.  He walked us through many use examples, using humorous anecdotes to demonstrate that the importance of trust is growing and growing.


This post syndicated from: Thoughts on security, beer, theater and biking!

Tuesday, September 24, 2013

ICMC: Introduction to FIPS-140-2

Presented by Steve Weingart, Cryptographic & Security Testing Laboratory Manager, at atsec information security.

While I'm not new to FIPS-140-2, but as I'm here in Gaithersberg, MD for the inaugural International Cryptographic Module Conference, it's always good to get a refresher from an expert.  Please note: these are my notes from this talk and should not be taken as gospel on the subject. If you need a FIPS-140 validation - you should probably engage a professional :-)

Since the passage of Federal Information Security Management Act (FISMA) of 2002, US  Federal Government can no longer waive FIPS requirements. Vendors just simply need to comply to various FIPS standards, including FIPS-140-2 (the FIPS standard that is relevant to cryptography and security modules).  Financial institutions and others that care about third party evaluations also want to see this standard implemented.

Technically, a non-compliant agency could lose their funding.

FIPS-140 is a joint program between US NIST and Canadian CSEC (aka CSE).

All testing for FIPS-140 is done by accredited labs (accredited by National Voluntary Laboratory Scheme).  Labs, though, cannot perform consulting on the design of the cryptographic module. Could be seen as a conflict of interest, if they were seen as designing and testing the same module.  They can use content you provide to make your Security Policy and Finite State Machine (FSM), as those documents have to be in a very specific format that individual vendors will likely have trouble creating them their first time out.

A cryptograpic module is defined by its security functionality, well-defined boundaries and have at least one approved security function.  A module can be contained in hardware, software, firmware, software-hybrid, firmware-hybrid.

Security functionality can be: symmetric/asymmetric key cryptography, hashing, message authentication, RNG, or key management.

The testing lab makes sure that you've implemented the approved security functions correctly to protect sensitive information, makes sure you cannot change the module after it's been validated (integrity requirement), and that you prevent unauthorized use of the module.

Your users need to be able to query the module to see if it is performing correctly and to see the operational state it is in.

FIPS-140 has been around, originally as Federal Standard 1027, since about 1982.  Of course, as technology changes, the standard gets out of date.  FIPS-140-2 came out in 2001 with some change notices in 2002.  FIPS-140-3 has had many false starts.  A large quantity of implementation guidance has come  out (the IG is approaching, if not overtaking, the size of the initial FIPS-140-2 document).

Some brief clarifications: the -<number> on the standard refers to the version.  The first was FIPS-140, next FIPS-140-1, and the final currently adopted one is FIPS-140-2.

Each of those versions have levels that you can be evaluated at. Level one is the "easiest", level four is the hardest (available to hardware only).

FIPS-140-3 has had two rounds of public drafts, there were over 1200 comments, but it seems there is just one person still working on this draft.  In addition, there are not any Derived Test Requirements (DTR) so the labs cannot even consider writing tests for the standard.

There are new versions of "FIPS-140-3" by ISO (19790)  (released in 2012), essentially competing with the NIST draft.  Though, the original goal was to have the ISO standard be the same document, just as an international standard.

Right now, you can validate against the ISO standard in other countries - not in the US or Canada, though.  If you used an international body to validate your module against the ISO standard, it would not get you through the door to US or Canadian Government customers.

It's up to NIST and CSEC to pick one of these, create transition guidance and testing information to let vendors and labs move forward.

ISO 19790 has many improvements, but if you implement them, you will not pass FIPS-140-2 testing. For example, ISO 19790 allows lazy POST (only testing when needed), but FIPS-140-2 requires POST of the entire boundary any time any part of the boundary is used.

FIPS-140-2 has four levels, and it doesn't matter if 99% of your module meets all of the items required for a higher level (like level 2) - but 1% only meets level 1, you cannot be validated at the higher level.

The ISO document doesn't point to specific EAL common criteria levels, helping to alleviate the chicken and the egg circular dependency for FIPS-140 levels. For example, FIPS-140-2 Level 2 requires a EAL validated OS underneath.  The EAL validation requires a FIPS-140-2 validated crypto module.

The finite state model means that you can only be in one state at one time. That means you cannot be generating key material at the same time you're performing cryptographic operations in another thread. This can be very difficult to accomplish with modern day multi-threaded programs - the labs that do the validation review source code, too, so no sneaking around them!

Mr. Weingart keeps reminding us that FIPS-140 is a validation, not an evaluation.

There are some good questions about how do things like OASIS KMIP interact with the requirements for FIPS-140-2 cryptographic key management requirements?  The general thought is they should harmonize, but KMIP doesn't seem to be referenced.

Around key generation, RNG and entropy generation is very important, and with the current news - this is being heavily scrutinized by NIST right now.  Simply using /dev/random (without knowing anything about its entropy sources) is not sufficient. Of course, when you're also the provider of /dev/random, you have a bit more knowledge. We should expect further guidance in this area.

Cryptographic modules have to complete power on self-tests (POSTs) to ensure that the module is functioning properly - no shortcuts allowed! (again, your code will be reviewed - shortcuts will be seen!).  There are also some conditional self-tests - tests run when a certain condition occur, for example, generating a key.

If any of these tests fail, you must not perform *any* cryptographic operations until the failure state has been cleared and all POSTs are rerun.  That is, even if your POSTS for SHA1 fail, you cannot even provide AES or ECC.

If you make any additional "extra credit" security claims, like "we protect against timing attacks", that either needs to be  verified by the lab, or a disclaimer needs to be placed in your security policy.

Implementation Guidance

There is a lot of new implementation guidance coming up, fast and furiously.

The most contentious one is the run Power on Self-Tests all the time (whether in FIPS mode or not). This can be problematic, particularly for something like a general purpose OS or smartcards. Things that may not have been designed for this, or that just don't have great performance capabilities (like smartcards) this can make your device or system unusable for customers that do not need FIPS-140 validated hardware/software.

IG G.14, for example, has some odd things on algorithms, like RSA4096 will be removed from approval, but RSA 2048 won't be. This seems to be related to performance issues, according to discussions in the room, but that seems a harsh punishment for perf issues.  Check SP800-31A for more details about what will and will not be allowable going forward.

Cryptographic Algorithm Validation Program

Any algorithms used in approved mode need to be validated to make sure they are operating correctly.  This step is required before you can submit to the CMVP  (Cryptographic Module Validation Program).  This is a very mechanical process - you have either passed the algorithm tests, or you haven't.  CAVP turn around to issue certificates for your algorithms is typically very quick, because there isn't wiggle room or room for interpretation.

You will work with labs (22 approved ones that are accredited currently) on this, and a consulting firm that will help you to work with the labs, work on your documentation, design, architecture, etc.  You can hire another lab as a consultant, just your lab cannot consult for you. (back to that they cannot test what they designed)

Preparing yourself for validation

Read FIPS-140-2, implementation guidance, SP-800s documentations, etc.

Take training, where available and possible.

Enlist help on your design and architecture as early as possible, get a readiness assessment.

You can do your algorithm testing early, find and fix problems early in your development.

Iterate as needed (if this is your first time, you'll almost certainly have to iterate to get this right).


This post syndicated from: Thoughts on security, beer, theater and biking!

Friday, September 20, 2013

PKCS 11 Technical Committee Face to Face

This week, Oracle hosted the OASIS PKCS 11 Technical Committee's face to face meeting on our Santa Clara campus.

It was a very productive two days, I believe we got through some of the final issues to the next revision of the standard (v2.40).  Work won't finish there, it seems, as all of the committee members are excited about what we can do in the future to make PKCS 11 an even more robust interface for providing cryptographic services to applications and utilities.

As most of you already know, Solaris's user level Cryptographic Framework is a PKCS 11 API, so we're very excited to see the standard progress and evolve.

As co-chair of the committee, I am so proud of everyone's hard work in dusting off the standard and doing the hard work necessary to quickly converge to get the next revision ready to go!

The standard moved from RSA to OASIS earlier this year.

Thursday, September 19, 2013

ICMC: Presenting on Software in Silicon: Crypto-Capable Processors

I will be co-presenting on crypto-capable processors at the inaugural International Cryptographic Module Conference next week, along with Dave Weaver (SPARC architect), and Wajdi Feghali (Intel).

We'll be talking about the evolution of cryptographic instructions in general purpose processors, using Solaris as the case-study example.

Are you interested in cryptographic modules, FIPS-140 validations, or crypto stuff in general?  You should register for next week's ICMC conference in Gaithersberg, MD! There's a few days left to register.

Thursday, June 20, 2013

Most Influential Books in my Life

These books have changed the trajectory of my life. I've read many other good ones and have a 2 foot stack next to the bed of "to-read", but these are the books I think back on, re-read, reflect on and have changed the way I live my life.  Yes, I mean that. Changed my life.

Influence: Science and Practice

This is a short book that's just jam backed with information.  This is a science based approach to understanding how to influence others and, most importantly, to realize when you're being influenced!  Robert Cialdini covers everything from salting tip jars to how a car dealer pushes you into a car sale.

I learned simple things to getting people to do what you ask: get them to verbally commit - or even better, in email/writing. People love to be seen as "consistent", so even if they get more information later they will stick with their original statement and even create reasons why it's the correct one.  It is great when I can catch myself doing this - but is also handy when you want people who, let's say, join a group to commit to performing a certain task.

[Aside: This is what gets politicians in trouble, in my book. They don't want to be seen as "flip-floppers" so even when they are presented with new information, they refuse to change their opinion. That's absolutely horrifying to those of us with background in science and those that know the value of data driven decision making.]

For example, this is why it is important for theater producers to make sure they get all actors to sign a form committing to the performance. Each actor has just now promised they will do the show, so it will take something extreme for most to back out of the show.  I know I've stayed in shows that I was not happy with for that very reason - well, and not wanting to get blacklisted from a theater group as well!

Having this knowledge also helps you to influence your peer group and others at work, and to protect your self from compliance professionals. This should be mandatory reading in all high schools and colleges.

This book is powerful, and when you read it, you MUST promise me you won't use it for evil.

Women Don't Ask: Negotiation and the Gender Divide

This book was recommended by the incomparable Valerie Aurora, who even set up a scholarship for this book, so that more women could read it and get access to it.  Before I read Linda Babcock and Sara Laschever's book on Gender and the Negotiation Divide, I had no idea of what I was missing out on by just not asking for what I wanted!

As a good student, I was used to being recognized for my efforts - I'd get an A on a test for studying hard. Very simple effort/reward dynamic.  It's different in the real world.  If you work really hard on a project, but don't tell others why you are doing it (for a raise, promotion, comp time off, recognition, etc) - you may be lucky if you get a pat on the back in the end. You've got to say, "I'm working my tail off on this project, which is not what I'm really interested in, so you can see how dedicated I am and make me the lead of the next, more interesting project."  Or, "I really want to take a few extra days off for my honeymoon. I'm willing to work a few weekends to make sure the project is done before I leave, if I could then have a few more paid days off. Does that work for you?"

I was also blissfully unaware that most men do ask for what they want and need.  This isn't small potatoes, this stuff adds up.  A small salary negotiation before you start your job can make a big difference in your salary and retirement savings just 10 years down the road.

Most surprisingly?  Most people don't say "no" when you ask for something reasonable.  Since reading this book and "Influence: Science and Practice" , I've gotten discounts on furniture, appliances, clothing, shoes and services.

I'm by no means an expert negotiator, nor am I one of those annoying pushy people we've all met. Neither Women Don't Ask nor Influence are asking you to become pushy.

I just simply ask.

People do not read your mind. You must ask. You'll be surprised what happens.


Leadership Presence

My old mentor recommended this book to me - bringing two of my favorite things together: theater and corporate leadership. Belle Linda Halpern and Kathy Lubar use years of their own personal research and their study of theater actors into what makes a good leader.

Empathy and mindfulness are two big take aways from this book. How can you lead a team if you don't have any empathy with them? If you are not self-aware, you won't see the mistakes you're making or how you are making people uncomfortable - that's where mindfulness comes into play.

The anecdotes resonated with me, and I find myself reflecting back to them often.  How can I play a character that I can't relate to?  On stage, now, I always have a back story for my character. I always find some part of me in them and vice versa. For the first time, I've been able to cry real tears on stage.   Not stage tears. Not fake tears. Real tears.

I recall rehearsing for Best Little W*****house in Texas. I was playing a character named "Shy". She had run away from home because her father molested her.  I do not share that experience, so I read about the real women who worked at the famous Chicken Ranch. I read about how molestation breaks a young child. I listened to stories on Love Line. I found the pain, the heartbreak.

Running that scene where Shy tells the madam about her father over and over again in rehearsal physically and mentally exhausted me. Even now, I am tearing up writing about this.

Shy was not a real person, but her story was based on many real women who had lived this. I put myself in her shoes and I felt it.  [Aside: I'm in no way saying I truly understand what someone in that situation feels or went through, but merely just a slice of that. A moment.]

I do this as well in the corporate world now: I listen to my team members, hear what is going on with them, I listen for vocal variations and physical cues that tell me when someone might be uncomfortable. I take all of this in before I speak, and I'm finding it's easier to find out what works and what doesn't.

Additionally, when I do presentations now at work, I am actually acting. I think about people who I like seeing their presentations, and I simply take on that role when I get up in front of people. It's amazingly effective.

Crucial Conversations Tools for Talking When Stakes Are High

I once got in trouble at work for saying "no" too often as the technical lead of Solaris 10 Update 1.  For those of you who have been a technical lead of a large project, you know it's your job to say no - when appropriate. You need to maintain high quality, meet the customers needs and stay on schedule.

This was very frustrating when my upper management didn't "get it" and told me that I had an attitude problem.  I was irritated and hurt.

One week, the program manager for one of the projects trying to integrate into my gate complained to my upper management about how unhelpful I was and how I didn't have good reasons for my "no".  That same week, the engineers and managers on that same team brought me a literal mountain of chocolate to thank me for my patience and helping them to understand why they weren't ready and helping them get to the place they needed to be. A little behind schedule, but with the necessary quality we demand. Of course, they didn't go and compliment to my upper management.

So, I had to take this class. Being the good student I referenced earlier, I bought the book in advance and started reading it.

Wow.

Okay, so I had every right to say "no" to some projects, but how I said it and how I listened - boy, that makes a big difference.

The biggest takeaway from this book, that I still use every day, is that humans use shortcuts. We have to. We're too busy. Part of that shortcutting is to tell stories to fill in the gaps of something you hear from someone or something you see.

For example, I might see a man hold a woman's arm and my brain fills it in with the story that they are dating, but really she may have just slipped and he was helping to stabilize her or she is blind. My story is wrong, but quick.

When someone comes to me with a demand at work, I could say that they are doing it because they are an asshole who doesn't understand the process and is trying to get someone else to do their job.  Or I could tell the story that they are overworked because their boss is out on emergency medical leave and they are suddenly on multiple projects, so they are seeking help.
Neither of those might be true, but being aware that each person has a motivation for their actions, and it's rarely "because I want to be an asshole" has again helped me to live for a moment in someone else's shoes.

Another great thing I learned was how to know when my brain was taking other shortcuts that weren't going to be good.  That is, when is the lizard brain kicking in?  For me, I get tense and get butterflies in my stomach.  Now when I feel this, I realize my "fight or flight" instinct is kicking in and that I need to be careful not to raise my voice, take a deep breath, and tell alternate stories for the others - or, heck, just ask them, "what are you trying to accomplish?"

Atlas Shrugged

Whether you love or hate Ayn Rand's Objectivist philosophy or the woman herself, you have to admit she had a novel way of presenting philosophical ideas to the masses.  An ex of mine told me he thought I'd like the book. I couldn't put it down (okay, I always skip most of John Galt's ridiculous 60 page speech), but this book changed the way I read fiction, opened my eyes to a philosophy that seemed to have great promise in impacting the way we all lived.  I joined the Objectivist club on campus at Purdue, met many intelligent people and had great in depth discussions on Ayn Rand's philosophy.  I never agreed with everything she said, and I must say I am greatly disappointed at people who have taken this philosophy to the extreme to the detriment of others.  I am disgusted by what has happened when classically public run things like prisons are privatized (for example, in AZ the private companies running the prisons lobbied for MORE laws so that they could get more prisoners and make more money).

But, beyond all of that, this book opened my eyes to a  new way of thinking. A place where rational thought and logic were supreme and had merit. Showed me that I could apply logic to making decisions about my life. I did not merely need to let things happen to me, but could control what was around me.  I didn't need to stay friends with someone, if the friendship was toxic, just because it was the "nice thing to do". I didn't need to work myself to the bone for someone else for no reward.

Yes, Rand's characters are very black and white, and the movie was just awful, but as a young college woman, these new ideas changed my life.


What books have changed your life? Thoughts about any of mine?

Friday, June 14, 2013

45% of gamers are women, but don't you dare suggest women be the protagonist in a game!

Maybe it's just me, but some days I really feel like things are getting worse in the tech industry.  These two articles came across my twitter stream this week that seem like they must've been written on different planets.

The first one is from SF Gate where Derrick Lang noted the low number of female attendees at the E3 gaming conference, and how that was surprising because 45% of gamers are women. Let me say that again: 45%!

This was explained away that E3 was more for developers and not consumers (back to my post from last week).

That aside, how can I now explain that in the same universe, Anita Sarkeesian was attacked online for complaining that the latest XBox console launch didn't include any games with a female protagonist.

The attacks included these gems:
aurini-jerk
b_razz-jerk1
beatanddelete

How is 45% of the marketplace not a significant number?  How is it that more than 50% of the human population is neither interesting nor capable just because of their gender?

Friday, June 7, 2013

When Geeks Attack: Marie Claire Article, featuring me.

My heart has been broken over and over again by the recent news stories about women in tech simply being attacked online. What's worse, is when someone like Alissa Quart writes an article about the types of online abuse women face along with in person abuse at conferences, she herself becomes a target.

Let me say, that I've been to many awesome conferences where nothing worse than a bit of mansplaining occurred.  But I've also been to my fair share where people called me a "scene whore", constantly asked who my boyfriend was (because why would a woman attend a technical conference by herself?), and flashed me (yes, a man showed me his genitalia on the conference room floor), to know that not all conferences are equal.

+Valerie Aurora started the Ada Initiative to help conference organizers make their events more female friendly, and encourage participation of women in Open Source.  Those of you that know Val know how active she's been in Linux and Solaris kernel development over the years: she's smart and compassionate.

Val and I met at an early DefCon - 3 or 4? At the time, still a small community with mostly nice guys (I only got 1 or 2 creeper emails following my first DefCon - which was also the last one where I used my real handle on my badge).  The conference is much larger now, and has definitely had some growing pains. It's definitely a place where you'll meet really awesome people and learn fascinating things - but there are less savory people there as well.

I have my DefCon stories. After seeing the fallout on other websites about this article and to the Ada Initiative blog entry that seemed to shine the light brightest on all of this, though, I don't feel comfortable sharing the details at this time.

Marie Claire

Val and I were both interviewed by Alissa and photographed by Nicolas Silberfaden, a strange thing for both of us.  Two nerds in a fashion magazine? And both named Val? 

Please do check out the article.  You can find it online, but neither Val nor I had our pictures in the online version. To see our pics, you'll need to pick up the June 2013 issue of Marie Claire at any store that carries magazines.

Update: There's a great article from The Raw Story about online and in person sexual harassment covers the odd phenomen we're all witnessing now where the harassment is seen almost as a game, and when someone like Val tries to speak out against it, she's seen as a "Feminazi" and being overly political.

Wednesday, May 29, 2013

Poised For Leadership

NetApp hosted the latest Jo Miller's Women's Leadership Coaching workshop: Poised for Leadership.  As always, I enjoyed Jo's workshop and was thrilled to be able to participate in a full day event with her for the first time.  The time spent here helps to reinforce things I have begun to put into practice and reminded me of things I need to continue to invest effort into.

As emerging leaders, we can often find our selves in a quandary: we an't get to a higher level job without leadership experience, but can't get that experience without the next job.  When you find yourself in this position, you need to take the steps to get the recognition you deserve. Do not be "the best kept secret" in your team.

To do this, you need:
  • Organizational Influence
  • Sphere of Influence
  • Leadership Brand
  • Visibility
  • Influencing
  • Self-Leadership
What does being a leader mean? Leading by example, developing a vision, not disheartened easily, genuinely cares about the people and the business, collaborates up, down and across for success.

Organizational Influence

Like it or not, "every workplace has an intricate system of power , and you can - and should - work it ethically to your best advantage." (Erin Burt, Seven Career Killers)

Don't think of this as Office Politics, but rather Organizational Awareness. Observe what's going on around you, and perhaps modify your behaviour and your language to adapt.

Part of this is being aware of the shadow organization.  Like you're standard org chart, but based on people's organizational influence. Take a look at your existing organization. Find people who work well together - a good solid relationship, and draw a line.  Find people who do not work well together. Then find the coalitions - groups of people that work well together. Finally, identify the key influencers in the organization.  See where you fit into all of this.  Are you reaching outside of your immediate organization?  You need to build robust, professional relationships with key people around you.

Don't count on your sphere through normal meetings. Set up lunches with individuals or small groups, don't eat lunch at your desk, bring in cake or chocolate to share: get to know people outside your immediate teams.

Be aware of the unwritten rules of the game. Something like, there may be a person that you cannot correct in front of others in a meeting, without burning bridges. In some groups, you may need to shop around new ideas before implementing them - or your group may be "Act first, ask questions later" type of org.  You need to know the specifics for your team.

In some organizations, it may the words you choose.  Your VP may not like any vocabulary that hints at entitlement for what you're asking for, or they may only want to take action on your ideas if you have data to back up your request.

Sphere of Influence

We've heard it a thousand times, but your network is so important to your success. You need to grow your sphere of influence.  You need connections. These connections and mentors will help you to enjoy more promotions, higher pay and greater career satisfaction.

Building these networks can help your next big job find you.

Don't build these networks with only your personal advancement in mind. Get to know different things about them, figure out how you can help them to advance, find opportunities for them.

Part of building your network is making sure you're adding key types of people to your network:
  • The connector
    • A true people person, knows and gets along with everyone, loves to open doors and make introductions.
  • The Informational Powerhouse
    • Keeps their finger on the pulse of the business, knows about changes before they occur, filters useful information from gossip or noise.
  • The Influencer
    • Not necessarily high-level or high-profile, but has the ability to make things happen.Their advocacy can get you noticed and guarantee success of your initiative.
  • The Mentor
    • To best take advantage of your mentor, be prepared with four types of questions for them:
      • Stories about their careers
      • Situations you're in that you need help with
      • Self-awareness is important. Know how you're perceived. Ask your mentor to reflect back.
      • Skill building: ask about any new skills you're trying to learn in your role.
  • The Sponsor
    • Echoing what Jo has said at every workshop I've attended: beyond mentors, you need sponsors.  Women tend to be over mentored and under sponsored. Sponsors should have the following qualities:
      • Senior leader with influence
      • Well-respected, credible
      • Familiar with your strengths
      • Track record of developing talent
      • Provides exposure and protection.
    • How to get a sponsor?  Outperform, make your value visible, ask around to see who has a strong track record of developing talent, network outside of your direct management chain and have clarity about your career goals.

Leadership Brand

Knowing your current brand is important. Do others see you as you see yourself?  You can learn this by:
  • 360 Review
  • Ask friends and colleagues for 3 things that describe your positive traits, one thing to work on.
  • Ask your mentor, friends, tweeps, etc
Most importantly, though, you must be ready and open for this feedback.

You need to identify what you're passionate about and what you're good at.  What do people complement you on that you think was "easy" to do? That could be one of your key skills or talents.  When this lines up with something that your company or industry needs or values - then you've found a career sweet spot.

Funny, quite a few women in this room know what their skills and passions are, but they cannot find how it fills a niche in their current job.  As an aside, everyone here is very successful and on their way up in their careers - so are they really in the wrong place?  Or not seeing the fit due to low self confidence? Or possibly, they haven't found the right end goal quite yet.

You may already have a brand, and it may fit what you're doing now - but it's not your long term goal. Then it's time to update your brand.   Shop it around, let people know what you want to do and where you want to go. Bounce ideas off of your colleagues.

Brands evolve. Entry level brands could be things like: team-player, valuable contributor. Examples of mid-level brands: strategist, innovator, subject matter expert, change agent, fixer.  Senior-level: Visionary, leader who develops leaders, rainmaker.  What do you think your brand is? What would you like it to be?

Visibility

No matter how many accomplishments you make, if your accomplishments are not visible, you will not be rewarded.  Hard workers attract more work, which won't necessarily get you any recognition.  Part of getting this visibility means spending a little less time working on the minutia, and work on making your accomplishments more visible.  Resist the tendency to talk about the busy work. Share the strategic high impact stuff. You'll attract more of what you talk about - so it seems like an obvious choice.  Along those lines, work hard on the right projects.

It's important to share this appropriately - who needs to know what you're doing?

To do this, it's important to choose the right projects. Find things that will showcase your brand and demonstrate your ability to deliver results.

Once you've got all this down, then you need to promote your accomplishments!

This is tough - you don't want to be that annoying person that seems to never shut up about all the little things they do (minutia!),  so think back to what needs to be known and get it in front of your organization.  Here are some easy tips:

  • Present in meetings, invite leaders
  • Send out a newsletter or regular status updates
  • Submit article to your organization's newsletter
  • Write a blog or paper
  • Ask to be nominated for an award (or ask a colleague to do so, and reciprocate)
  • Forward kudos emails to your management chain
  • Water cooler conversations, lunch table topics.

Influence

You can't just drop into a meeting and influence decisions - first you have to set yourself up as a person of influence. People have to know who you are and respect your thoughts.  That can be done by simple things - show up to meetings, be engaged, make sure people around the table know who you are. 

Our behaviour teaches others how to treat us.
"It's not what you know, or who you know.  It's who knows what you know." - Norah Denzel, Intuit.
Jo sees there are 6 major sources of influence:
  • Positional Influence
    • Influence that is inherent in your job title and role.
  • Expertise Influence
    • The influence that comes from your background, qualifications, experience and accomplishments.
      • Sharing your accomplishments is good: speak on panels, at conferences, and in the media. Volunteer for high level assignments, etc. Get your expertise out there!
  • Resources Influence
    • Negotiating the resources you need to do your job well.
      • This will help you accomplish what you need to do, and demonstrate that you use your resources wisely
      • Master matrix management
      • Suggest special projects as developmental opportunities.
  • Informational Influence
    • Having a finger on the pulse of what is going on in your organization, industry and profession.
    • Keep up to date with current events in the industry - this helps you be on the look out for new projects and opportunities, setting the direction for your team.
  • Direct Influence
    • Being firm, professional and direct when someone's behavior is detrimental to the team or the organization.
      • Be direct and concise while delivering tough news
      • Share a vision of their future potential.
  • Relationships Influence
    • The influence that comes naturally with having a network of authentic relationships across your organization, industry and profession.
    • AKA Your Sphere of Influence!
How many of these do you have? Can you think of ways to expand into some of these other spheres of influence?

Your Pitch

Prepare yourself a 30-second commercial:
  • Name
  • Job title and/or brand
  • I am responsible for ...a, b, c
  • Come directly to me when you need ... x, y, z
This is an important thing to have in your back pocket. I've written this done a few times, but haven't memorized it. As I won't literally have this written down in my back pocket, I need to take the time to do this.  What's your pitch?

Principles of Self-Leadership


  • Confer Leadership Upon Yourself
    • Don't be afraid to take the lead. Start with leading yourself: set schedules and meet them. Look at ways you can lift others up around you and lead them to success as well. You don't have to be in an official leadership position in order to do this.
  • Act "As if"
    • Remember, much of your ability to lead has to do with wether or not others see you as a leader.
Book Recommendations


From my table and from Jo Miller.