These positions are:
Senior Software Architect (1 opening)
Secure Software Engineer (6 openings)
Usability & User Interface Specialist (1 opening, 9-12 month temporary position with permanent placement option)

Contact Andrew Robinson for more information,  atr AT maine.net

Senior Software Architect (1 opening)

Description:
- The Senior Software Architect (SSA) will report to the CTO
- The SSA will design and implement the development environment, including the underlying IT infrastructure
- The SSA will design, document, and implement, and enforce a rigorous RAD-based secure SDLC
- The SSA will manage the software engineering team including programmers, testers, UI architects, and other related functions
- The SSA will function as a member of the programming team

Qualifications:
- US citizen or permanent resident (non-citizens will be restricted from access to some information and operations)
- 10 or more years in a leadership role in both software engineering and SGRC
- Demonstrated experience implementing secure SDLCs
- CISSP _and_ CSSLP certifications preferred but not required (both certifications must be obtained within 6-12 months after hiring)
- PMP certification is “a plus,” but demonstrated large project management experience is even better
- Strong basic information technology skills
- Experience with Java, Java enterprise components, JavaScript, HTML5, and mobile platforms
- Excellent technical writing skills
- *CRITICAL* The ability to rapidly assimilate and use at an expert level new languages, platforms, and technologies
- *CRITICAL* Eager and able to engage in all aspects and phases of the SDLC

Compensation:
- Base salary between $90,000-$120,000 based on experience and qualifications
- Fully paid medical insurance for employee (spouse and family available through payroll deduction)
- Company supplied 3G/4G smart-phone and tablet (person use permitted), upgraded every 2 years
- 35 days of paid leave (“flex time”) per year
- Profit based bonuses after first year
- Casual work environment

Secure Software Engineer (6 openings)

Description:
- US citizen or permanent resident (non-citizens will be restricted from access to some information and operations)
- Each Secure Software Engineer (SSE) will report to the Senior Software Architect (SSA)
- SSEs with the most experience and aptitude will be placed in management positions as the team grows
- SSEs design, implement, document, and test business and presentation (logic) using a secure SDLC under the supervision of the SSA
- SSEs write and maintain user and developer documentation for the application(s)
- SSEs will directly support customers and users
- SSEs will support the organization’s IT infrastructure on a rotating, 7×24 basis
- SSEs will rotate through various functions in the software engineering team, including developers, testers, IT support,  and other functions.

Qualifications:
- 3-7 years of experience with both software engineering and SGRC
- Demonstrated experience or ability working within secure SDLCs
- CISSP _and_ CSSLP certifications preferred but not required (both certifications must be obtained within 6-12 months after hiring)
- Strong basic information technology skills
- Experience with Java, including Java enterprise components, JavaScript, HTML, XML, and mobile platforms
- Excellent technical writing skills
- *CRITICAL* The ability to rapidly assimilate and use at an expert level new languages, platforms, and technologies
- *CRITICAL* Eager and able to engage in all aspects and phases of the SDLC

Compensation:
- Base salary between $60,000-$90,000 based on experience and qualifications
- Fully paid medical insurance for employee (spouse and family available through payroll deduction)
- Company supplied 3G/4G smart-phone and tablet (person use permitted), upgraded every 2 years
- 35 days of paid leave (“flex time”) per year
- Profit based bonuses after first year
- Casual work environment

Usability & User Interface Specialist (1 opening, 9-12 month temporary position with permanent placement option)

Description:
- The Usability & User Interface Specialist (UUIS) will report to the Senior Software Architect (SSA)
- The UUIS will work directly with the software engineering team on a full-time basis
- The UUIS will take a leadership role in the design and evaluation of the application user interface
- The UUIS will organize and maintain the end-user guide for the application(s)

Qualifications:
- US citizen or permanent resident (non-citizens will be restricted from access to some information and operations)
- 3+ years of experience as a usability consulting and/or user interface designer
- Demonstrated experience or ability working within secure SDLCs
- Strong technical writing skills

Compensation:
- Base salary between $40,000-$70,000 based on experience and qualifications
- Fully paid medical insurance for employee (spouse and family available through payroll deduction)
- Company supplied 3G/4G smart-phone and tablet (person use permitted), upgraded every 2 years
- 35 days of paid leave (“flex time”) per year
- Profit based bonuses after first year
- Casual work environment
- PERMANENT PLACEMENT OPTION (for UUIS candidates who have or develop SSE-level capabilities)

Home sick today so I was catching up on some reading and came across “The Prolierfation of Cyber Janitors” by Jeff Bardin. I have to say that I had to re-read it a couple times to let it sink in. The gist of the article seems to be that security organizations are spending too much on “detect and respond” capabilities and not enough on proactive security measures. The principle is simple and correct….if you prevent it from “spilling” then you don’t need a janitor to mop it up. First off I think many information security professionals that are involved with incident handling and incident response probably do not like being called janitors. Jeff uses it for a bit of sensationalism or controversy. The title got me to read the article so mission accomplished I guess.

RSA chairman Art Coviello made a comment regarding breaches which in a nutshell said “It’s not a matter of if or when you will be breached, it’s a matter of how you will respond.”  To which Jeff wrote “This statement indicates that he is beaten. He has thrown in the hat with the not if but when statement. All because they were breached. “  Thrown in the hat? Art is stating what those of us who deal with security incidents have known for sometime but were somewhat ineffective in getting senior management to see:

1. If you have human beings using software developed by human beings on systems designed by human beings and connected to the Internet you are going to have a compromise. If you think otherwise then your head is firmly in the sand…..or elsewhere. Think about this in terms of physical security. Why do Security Operation Centers for physical security exist? Because people will try to break in and someone has to be ready to monitor for  and respond to that. Have organizations that built SOC’s for physical security also “thrown in the hat”?

2. Despite what the article says about the proliferation of CSIRT / CERT functions most organizations still are not equipped to deal with a compromise. Over the last 4 years I have had the opportunity to meet with many different security organizations and the majority do not have the processes in place to deal with a major compromise. I would argue that there aren’t  enough CSIRT teams out there.  Most organizations aren’t anywhere near the level of the Hanover Insurance security team that won awards when Jeff was the head.

To me the article seems to be implying the CSIRT’s rely on special technologies or products that come out the cottage industry mentioned. While many CSIRT’s may have some specialized tools (and usually built by them) they rely on the same tools and products that most likely already exist in the organization. A CSIRT isn’t about technology. It is about process. It is organizationally separating those who administer the security technologies from those who are looking at the logs and responding to the alerts. It is about dedicating some resources to very basic things that many organizations still don’t do, like looking at logs and doing root cause analysis. Security controls fail every day. Someone needs to have their eye on that ball.

I don’t argue that we need to be doing more to prevent. No I don’t mean buying WAFs or IPS. I mean addressing the root cause. Secure coding and change management principles are foreign to many, many organizations. User education is also lacking as a whole. I also agree with Jeff that a shakeup is necessary. However I do not think the shakeup needs to be in the security space. Security exists because something (outside of security) is failing. The root of the problem isn’t that security fails to be proactive. The root of the problem is that we need IDS, WAF, etc. in the first place. We do work in a reactive security world for the most part. In order to be proactive, security cannot be a technology. It has to be a principle that is part of all levels of the organization.  We have not reached that Utopian point where incident response and cyber janitors are not needed. I doubt I will live long enough to see that point. We need to react to what is happening now and plan for where we think things are headed.

I find this statement interesting. ‘We need true innovative thought that uses cyber intelligence, counterintelligence and active defense and offensive measures in our programs. ” Is it a coincidence that Jeff’s company (Treadstone71) offers those services? I’m not saying he is wrong. He is absolutely correct in that functions like cyber intel are sorely needed and do not exist in most organizations. You have to understand who your adversaries are, their methodoloiges and what they know about you. Those organizations which I have met with that have cyber intel / counterintelligence functions all have those functions in the same place.

Ironically it’s with the “janitors”.

–Chris

https://www.sans.org/security-training/reverse-engineering-malware-malware-analysis-tools-techniques-54-mid

–Chris

What I wanted to point out here is that you can’t have attribution with regards to an attack by only analyzing the tool used, no matter how through the analysis. We all know IP’s can be changed, compromised, rented out….so relying on that wont work. Code can be borrowed, stolen, reversed so that isn’t conclusive either. This especially true if we are talking about Nation State sponsored cyber attacks. The tool is only part of the bigger picture. Attribution requires taking a step back and looking at that this bigger picture.  Who received the email? What is their role at the company? Where did the adversary get their email address? What tools did they use once inside? What order did they use the tools? What time of day, week, month did the carry out the attack? How did they exfil the data? What did they do with the data once exfiltrated? These are just examples of data not directly tied to the code in the malware that needs to be analyzed. Threat actors have patterns that they follow just a criminals have M.O.’s. However these cannot be relied upon completely. Misdirection is your friend when you don’t want to be named.  A lot of data needs to be analyzed before you are in the position to claim attribution. I would argue that few organizations have the expertise and experience to do so and fewer still could say conclusively, outside of Defense and Intel circles.

Also remember that not all advanced intrusion are APT just as not all APT intrusions are advanced. What helps constitute the Advanced in APT is their ability to pick the right tool for the job. They are not going to pull out their 0-days unless they have to, in my opinion anyway.

–Chris

[TAGS] APT, RSA [\TAGS]

–Chris

Congrats to the team at, NitroSecurity. They were acquired by McAfee according to this press release today: http://www.mcafee.com/us/about/mcafee-nitrosecurity.aspx

Nice job guys and girls. It’s good to see a successful exit.

–Chris

For those Splunk users out there the 2011 Splunk Users Conference will be August 15 – 17 in San Francisco. http://www.splunk.com/view/SP-CAAAFCW

I’ve been a big fan of Splunk for a number of years. Somtimes you just want to search your logs and create / modify the queries on the fly. Splunk gives you the flexibility to do that. A SIEM is a great log tool but it is not always the right tool for the job. Incident Response is one of those processes that I think Splunk is ideally suited.

–Chris

Technorati Tags: Splunk

There was an article I read many years ago that was called something like “Why Johnny can’t encrypt”. The gist of the article was that email encryption (and the underlying technologies like PKI) were so poorly implemented that the average user couldn’t use them or understand them. In my opinion that is as relevant today as it was a decade ago. There seems to be 2 schools of thought as to why this is. The first is that the implementation and resulting user experience of these technologies frankly sucks so nobody wants to use them. The second is that the masses are not asking for secure email so what gets implemented is core functionality that is just enough to say it works, depending on your definition of “works”. Call it what you will but I believe if it was easy to use then more people would use it, even if they don’t fully understand the concepts.

So how far have we come? Let’s take a look at Blackberry 5.0 infrastructure and handheld OS to see how they well they have implemented S/MIME. Contrary to what you may think after this article I am a huge Blackberry fan. I think when it comes to enterprise grade handheld devices and infrastructure (i.e. the BES) they have got it right for the most part. Let’s take a look at some of the issues that we have found during our Blackberry secure email evaluation.

NOTE: It’s been a while since I was working on this. If I am mistaken on any of these feel free to correct me.

Not enough of email is downloaded to the device to verify the certificate
Blackberry devices download something like the first 2K of an email. In most cases this is not enough to verify the status of the signing certificate for digitally signed emails. You have to open the message and do a “more” or “more all” to get enough of the email to verify the signature. I am not sure why the BES cant verify the status on the server and just send the results of the signature verification.

Forwarding / replying S/MIME emails silently drops any attachments
When you forward or reply to a digitally signed or encrypted email with an attachment there is a problem. The recipient will not receive the attachment and you will not see an error. The email just shows up with no attachment or errors. This is apparently due to the architecture that RIM uses, specifically the Attachment Service on the BES.

Inconsistent certificate status messages
If you receive a digitally signed email that cannot be verified for one reason or another the colored line that indicates status will be Red. However the exact same email digitally signed and encrypted will have a Yellow line. Why does signed and encrypted = Yellow and signed only = Red????

Stale Certificate status
Blackberry devices have significant issues checking certificate status properly. One of the main issues is that the device is apparently trying to check the status of all certificates in the chain, either via extensions in the certificates or CRL / OCSP servers specified in the configuration. This includes the Root certificate. The Root certificate does not publish a CRL on itself nor will anyone else. There is no certificate status when it comes to the root certificate. This causes Blackberry to show a Stale Status since it cannot obtain the status of the root certificate.

Handheld devices require additional software
The Blackberry devices require that the S/MIME support package be installed. This is accomplished through the Desktop Manager application. Basically you install the Desktop Manager on your workstation, connect your Blackberry to your workstation then install the software. Sounds simple enough and it is for a user. That model breaks down quickly when you are talking about an enterprise that has dozens or hundreds of these devices. Pushing this as an over the air update would make it much simpler.

User’s private keys need to be imported manually
To get the user’s private keys installed on the Blackberry device you must again connect to the Desktop Manager. As noted above this is something that a few users can handle but becomes a huge support burden as the number of devices grow. This is a hard one to solve given that you need to be careful when dealing with a user’s private key. You shouldn’t (in my opinion) give the users private keys to the Help Desk and let them install them on the users’ device. I may be a bit more cautious when it comes to this than most but non-repudiation goes out the window as you lose control of your private keys. Many organizations stand up a Microsoft CA as part of the domain infrastructure. A link from BES to the CA that generates a new signing key and recovers any encryption keys then pulls them down over the air might be an interesting solution.

One thing I haven’t looked at is how many encryption certificates the device can hold. When my current certificate expires I’ll get a new one. Will the handheld be able to store both so I can read encrypted email that was encrypted with either certificate?

What has your experience been like?

–Chris

Technorati Tags: Blackberry, S/MIME, PKI

Starting Monday July 11th I will be working with a newly formed group at RSA / EMC that is focused on APT and SMT. For 3 years I have been on the front lines of this fight as the IT Security Manager for MIT Lincoln Laboratory, a Federally Funded Research and Development Center. Constantly being in the cross-hairs of state sponsored cyber attackers has been quite a challenge but also an incredible learning opportunity. Those of us who regularly deal with true APT and state sponsored attacks definitely gain a new perception and appreciation for what motivated, experienced and funded attackers can do.

It was definitely a difficult decision to leave the Laboratory. Working at the Lab was the second most personally rewarding position I have held, the NSA being first on that list. I will miss the many talented co-workers and friends I’ve made there. Those who know me well know that I seldom stay anywhere more than 3 or 4 years. I enjoy new challenges too much to stay in one place. I am really excited about my new role.

And before you ask…no I am not giving you any details on the breach

–Chris

 
The RSA SecurID token has arguably been the defacto second factor authenticator for many years. Despite the recent breach at RSA I do not see many organizations moving to alternate vendors or other second factor technologies, like PKI / SmartCards or telephone based solutions. In the wake of the RSA breach most companies seem to be replacing tokens and hardening their SecurID & Authentication Manager infrastructures and reviewing relevant security processes. I have seen a couple organizations look to add additional authentication methods to supplement existing SecurID implementations for remote access, like requiring PKI certs in addition to SecurID for Remote Access. Obviously this capability is dependent on your Remote Access vendor. If you are staying with SecurID for your Remote Access authentication you should be taking a hard look at your access logs. Below are some searches that you may find useful if your logging environment can perform them. The ability to perform GeoIP lookups and calculate temporal data is required for some of the searches. Many of these searches will require you to baseline this activity in your environment to reduce the false positives.

• Top 20 Remote Access source IP addresses for the last 30 days
• Top 20 Remote Access users for the last 30 days
• Remote Access attempt from non-US IP address
• Remote Access attempts at “odd” hours
• Remote Access failures from multiple
• Remote Access attempts from one IP address for two or more usernames
• Remote Access attempts for one username from at least two different IP addresses in XX minutes
• Remote Access attempts for one username from at least two different countries in an X hour period
• Remote Access sessions of longer than usual duration
• SecurID authentication attempt involving Invalid / Revoked / Expired tokens
• SecurID authentication attempts involving one username and multiple token serial numbers
• SecurID authentication attempts involving one token serial number and multiple usernames
• SecurID “Right Token code, wrong PIN” messages

There are probably others that can be added to the list.  Your RSA sales rep can provide you with a copy of their Security best practices guide for Authentication Manager as well as their Log Monitoring Guidelines. The NSA’s Information Assurance Directorate has also published an unclassified advisory on securing your SecurID infrastructure. If you Google it you should be able to find a copy.

–Chris

For those so inclined The sixth annual APWG eCrime Researchers Summit call for papers is out, as part of eCrime ’11.

eCRS 2011 will bring together academic researchers, security practitioners, and law enforcement to discuss all aspects of electronic crime and ways to combat it, Topics of interests include (but are not limited to):

Papers need to be in the IEE format: Submissions should be in English, in PDF format with all fonts embedded, formatted using the the IEEE conference template, found here: http://www.ieee.org/publications_standards/publications/authors/authors_journals.html.

–Chris