Analysis is the foundation of design: Analysis of requirements,
of your existing systems, etc. You have to know where you are first
in order to get where you want to go. Analysis doesn't have to be a
long drawn out process. I have an eye for commonalities with respect
to security and privacy that let me prune problems down to size.
In addition to the analysis I've done solo, I've also enabled engineers
at client firms to analyze systems that they initially said were
"too complicated". (Engineers love this -- and so do their bosses
who suddenly get traction on intractable problems.)
I can help you quickly get to a point where you are ready to do design. Then I can help you create a secure design that is practical and manageable. My resume lists examples of my analysis and design work (under Work Experience). Among other things I created a design for Harvard Medical School's IT department to help them automate provisioning and authentication of researchers from other institutions. That project including both analysis and design took under sixty hours.
I have a laser-like ability to cut through vendor claims and identify the actual pros and cons of a product given your circumstances. I'll help you get a product that meets your requirements. Speaking of which, let's talk about Requirements Development.
Accurate requirements are the foundation of a successful project. I can tease out requirements from the sometimes vague descriptions expressed by your customers and/or staff members. Requirements generation is its own art. Even gurus in your project's area don't necessarily have the skill set to figure out requirements. Reason: the requirements person has to be able to communicate with people who are not experts. As I'm sure you know, gurus don't always do end user-speak — or CIO-speak. I do.
"Accountability" in an IT security context is your ability as a system owner to figure
out who did what to which resource. Many legacy IT systems have their own authentication
and authorization subsystems built in. How do you put together new applications with
legacy data — and still keep the overall system secure?
Among the issues here are identity mapping, and credential (or attribute) mapping. Some solutions leave you without the ability to know who/what/which. Overly complex solutions are a nightmare to manage, but some typical simple solutions make accountability fly out the window.
I have extensive experience with authentication and authorization systems, and identity management and mapping. I can help you get better accountability (and overall security) in your systems that marry legacy and newer technologies.
Privacy is a hot topic, particularly in the medical field, private banking, and higher education. I've done significant work in privacy over the last fifteen years, including creating a policy language for user consent. Consent, in particular, is highly relevant to new data protection rules from the EU (the GDPR). The rules are European but affect US institutions. Upshot: I can help you design or enhance systems so that you can address your privacy and related compliance needs (as well as your security needs).
Feel confused by "security"? I can help you understand. For a quick look on how I think about security and how I explain things (for lay people) take a look at my essay "Ding-a-ling: A Wake-up Call on Risks and Consequences". You'll learn something important and might be amused along the way to boot. For a look at a more technical approach that is still aimed at non-experts see "RFID and Authenticity of Goods."
I did extensive work while at IBM on RFID. This work led me to write an article on "RFID and Authenticity of Goods". This article was published as chapter in "RFID: Security, Privacy, and Applications" ed Garfunkel and Rosenberg 2005. (I am the copyright owner.)
I have significant Common Criteria (CC)expertise from my experience as a key team member for the IBM SOA
Appliance Group's successful Application Level Firewall EAL4 evaluation. As part of a very small team, I interpreted
the CC rules, read thousands of lines of code so I could write the required "design documents," developed and
implemented the test plan, and did most of the interaction with the evaluators, especially during the
required on-site visit.
I can help you understand and get through the CC process. You don't want to go down this bumpy road with just the consultants from your evaluation team. Reason: They are experts in the CC, but they won't become experts in your product, and they won't/can't do the deep dive that's necessary if you are going for a significant evaluation level. Unless your most senior technical people are also very good writers, or you have highly technical documentation writers who can extract gold from you senior technical people, you are going to being doing a lot of rounds of document submissions and failures. [Caveat: This is my experience. If the consultants from your evaluation vendor are doing a bang-up job, then congratulations!)
Please see Accountability and Legacy Systems