On the 29th episode of The Silver Bullet Security Podcast, Gary talks with Dennis Fisher, executive editor of The Security Media Group at TechTarget. Dennis helps run SearchSecurity.com and Information Security Magazine. Gary and Dennis discuss the current “BS factor” in security journalism, shopping at TJ Maxx right after the TJX privacy breach, the state of software security, and which is harder: being a fry cook at Hardees or working as a PR flack.

• Dennis’ blog
• TJX
• Joe Walsh plays dirty laundry
• Software Security Grows
• Dennis’ un-named podcast
• Series of Tubes
• Hardees
• Nike/iPod

Formalize Requirements for long-term use

Now that you are making security development a lifecycle, it is time to lock down and formalize your security requirements. At this point, you need to take what you’ve learned and begin translating your security principles into something that can apply to multiple releases and multiple levels of your development process.

At a product level, you need to use the security rules created in prior projects to define long-term security requirements. Those requirements will become your core security policies.  Then, at the version level, you should create security requirements that are version-specific and are defined by the security objectives and features you want to address in that version.

Both of these sets of requirements can be formalized in a way that makes them easier to transfer across future product cycles and to modify based on the unique features or security issues of each version.  Making these a staple of your development lifecycle will also ease adoption of these requirements as team become familiar with them over multiple releases.

I would like to touch on one topic before moving on – enforcing requirements. As your team grows and your SDL matures, there is an inherent complexity that comes with managing and enforcing your requirements. In our experience, we’ve found that it is critical to identify a security advisor. Up until now, your company has probably had someone championing security and best practices – either as a formal role or simply as a informal advocate. However, making it a feature of your lifecycle requires dedicated effort to enforce and sustain the requirements as well as monitoring the security ecosystem for changes that may add requirements to your process. The security advisor(s) are the people who will help guide the creation of the security requirements both broadly and for each product cycle; for a smaller team, this may be a single individual. For a larger organization, a team of people may be needed. The security advisor should also evaluate your security policy and apply changes where needed, ensure the product bug database is tracking security issues that can be reviewed later (I’ll get to the Final Security Review in our next post), and guide the definition and enforcement of a security “bug bar”.

Security requirements serve as the backbone of your SDL. The amount of effort you put in defining and enforcing requirements, and keeping them up to date with the current threat landscape will have a direct return on investment in the security and privacy of the product you create. Be careful to document and clearly communicate your requirements to your team, and use them as evidence when talking to your customers about how you ensure the security and privacy of your product.

Reference & Reuse Threat Modeling results & Attack Surface Reviews

Your developers and testers should have access to and be familiar with the attack surface analysis or threat model documents you have created. These documents are invaluable reference tools. Use them to perform evaluate your security from multiple angles:

·         Think about component-level architecture

·         List common pitfalls in writing code, or begin defining and building test cases.

·         Code reviewers can reference threat models and attack surface documents to verify specific attacks were addressed in the code.

·         Architects can use them to identify new areas of potential attack surface based on how new code is written or interacts with existing code.

·         Project leadership can reference threat models or attack surface documents to ensure the completed project meets all security goals.

Building a “live” library of threat models that is accessible by everyone and is designed to be easily maintained or updated is a big undertaking. Based on experience, I would strongly encourage doing this early in the evolution of your security lifecycle to avoid losing valuable data and to prevent the sheer volume of data from becoming unusable. I have heard of some companies using wiki technology as their library for threat modeling while others may use searchable documents, spreadsheets, or websites to store/sort/share the information. Whatever method you use, it is important to anticipate the accumulation of a large set of information that should be easily used and shared across the organization.

I would like to do a deeper dive on the importance of security code reviews as part of your “walk” evolution. Security code reviews focus on identifying insecure coding techniques and vulnerabilities that could lead to security issues. The goal of a review is to identify as many potential security vulnerabilities as possible before the code is deployed. The cost and effort of fixing security flaws at development time is far less than fixing them later in the product deployment cycle [from Improving Web Application Security]. You should create a process where top security developers actively review code within the context of known threats prior to deploying your code. Leveraging the existing documentation about feature design is a vital reference piece to make those security reviews successful.

Later this week, I’ll close the series with a look at final security reviews (FSRs) and how to document your work for post-release and next-release reference.

In the meantime, we’d like to hear from you:

?        How do you express your security requirements? Do you use a checklist, a whitepaper, or something else?

?        What challenges have you faced in enforcing requirements across your teams?

?        How have you implemented threat models or attack surface reviews?

Well, no, security dweebs, we’re on a public policy kick, probably will be until the end of the year (more on that to follow, stay tuned), so you wouldn’t be so lucky.

The Plum Book’s official title is Government Policy and Supporting Positions and basically it’s a huge staffing chart for the Senior Executive Service–the political appointees.  Congress publishes the Plum Book after each presidential election, so for those of us who remember our civics lessons in high school, that would be every 4 years, and the last one was published in 2004.

In fact, you can see the last edition here.  Caveat:  it’s dry, like the uber-trocken Franken white wine that grows in the fields around where I used to live in Germany–so dry that it sucks the moisture right out of you.

Plum Pickin photo by Secret Tenerife

Now why do we care about the Plum Book?  Well, that’s a good question.  Have a look at some of the staffing plans in the plum book, and you’ll see something missing:  Agency CISOs.

Now, I’m not a rocket scientist on org charts, but it seems to me that unless you put CISOs up to where they’re answerable to the agency head, they’re just a cost center inside the IT department with no visibility to the decision-makers.  Once again, we’ve crippled our security staffs like the old-school way of doing things.

On another note, taking a quick straw poll of the agency CISOs that I know, I think about half of them are political appointees, and half of them are GS-15s.  So what’s the difference?

Well, political appointees (SES) are appointed by the President.  They make a better target because they have much more visibility from the higher-ups they are more political in nature.

GS-scale employees are civil service careerists.  Usually these are the guys who have moved up the ranks in the various agencies and know quite a bit of things.

Which is better?  Well, if you want survivability, then GS-scale is the way to go.  If you want to make the most difference, SES is the ticket.

Most of us will never get the choice. =)

Bookmark to:

The information security field is not yet fully mature; there is a lack of cohesive interoperable framework.   The rapidly evolving landscape adds to the existing problem. There are several examples: Intrusion Detection System (IDS) was quickly overtaken by Intrusion Prevention System (IPS).  On the Firewall arena: the focus has moved from perimeter security to end point security.  There are some security visionaries who are preaching inside-out security approach i.e. building products with information security in mind from the beginning.

Threats are moving higher up in the OSI stack making it harder to detect. Hackers are becoming more sophisticated – there are powerful free open source hacking tools available at their disposal. Security managers driving security initiatives without co-ordination can result in pieces of puzzle that don't fit well. Agency problem i.e. security managers thinking more about their personal advancement rather than security of the company is bad for the company’s security initiative. Security leaders who do not have a clear vision of

security at the component level, the administration level and the strategy level can only make information security even more convoluted. The CISO and acting CIO of US Dept of Veteran affairs resigned after the breach in May, 2006 where personal data of 26 million veterans and more than 2 million service members was stolen. This clearly demonstrates the accountability and visibility of security leadership.

The attitude of IT security leaders and security team members has a significant impact on security.  Reckless buying of information security technology can result in wasteful expenditure and very little gain in efficiency. Not understanding the business perspective of security issues or security perspective of business issues can lead to poor security decisions. Using security as a mechanism to gain control rather than using it as a tool to reduce risk can only diminish the perceived value of security initiative. Implementing security as an afterthought rather than building it into the framework not only result in poor architectural decision. Security investment is more like buying insurance. Thinking security as a vehicle providing an ROI can result in wrong expectation and lead poor decision. The business in which a company operates contributes largely to the perceived importance to security. Financial institutions usually have a higher bar on security because of the very nature of their business and their exposure legal liability. It is a good idea for many technology companies to emulate financial institutions to raise their information security bar.

It could be a pipedream to accomplish complete  information security but accomplishing a well managed information security program is an attainable possibility.

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts and topics.

1. Again this month, my logging polls took the #1 spot!  Poll #8 that covered context data for log analysis is analyzed here. Other popular polls include a controversial Windows Log Collection Poll (which is a poll #7)  and poll #6 about logs that people actually look and poll #5 about logging challenges. Next poll is coming soon.
2. Not entirely surprising, my post/rant called "You Are "A Security Idiot" If ..." takes the #2 spot after being live for only a few days. Yes, we all like to point out other people's problems, especially when they are epically huge :-)
3. Also not surprisingly, my post "11 Signs That Your SIEM Is A Dog or "Raffy, You Killed SIM!"" is on the Top list. It is both humorous and sadly true (and backed up by other sources)
4. A curious subject of DLP or "data leak prevention" (specifically, the post called "So, CAN We Have DLP?") also tops the charts. My previous post on data leak 'prevention' ("In Passing on DLP") is popular as well.
5. Again and again, people googling for "open source SIEM" have pushed this post (this tiny old pathetic blurb) to top5. This ancient post from years ago explains why an open source SIEM will NOT emerge soon, if ever.

See you in July!

Possibly related posts / past monthly popular blog round-ups:

• Monthly Blog Round-Up - May 2008  
• Monthly Blog Round-Up - April 2008  
• Monthly Blog Round-Up - March 2008  
• Monthly Blog Round-Up - February 2008  
• Monthly Blog Round-Up - January 2008  
• Monthly Blog Round-Up - December 2007  
• Monthly Blog Round-Up - November 2007  
• Monthly Blog Round-Up - October 2007  
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007

After hearing his speech, I thought about how Eric and Google are impacting the digital revolution after so many others have tried unsuccessfully over the last 25 years. He has led the company through a period of explosive growth from $1 Billion to over $16 Billion in the past year, while keeping the young, fun, irreverent culture intact. Considering the meteoric rise of Google’s popularity in a reasonably short period of time, to the point that the company name is now actually a verb!

The point that I found enlightening was his summary, which you can scroll to at the 26 - 30 minutes timeframe in the presentation, where he shared an interesting glimpse into the culture of Google. “Creating more luck, giving yourself more at bats, being out there… to think big and inspire a culture of YES.” The culture of Yes inspires people to aim higher and be ambitious in their reach and goals.

That is a very interesting point in which I really believe. If there is one thing that all companies and especially small companies struggle with because of natural resource constraints, it is building a strong culture of Yes. We have tried to do this from the very inception of ScienceLogic, but it continues to get harder and harder the larger the business grows. To consistently inspire a principle of Yes, without agreeing to every idea that flows across my desk is amongst the most challenging parts of our daily jobs. However if I could create the perfect scenario, we would intuitively strive for a principle of Yes and inspire our associates and our ecosystem of partners and customers to use this simple concept to confidently go forward.

Eric says, “It is possible to build a culture around innovation. It is possible to build a culture around leadership, and it is possible to build a culture around optimism.” Google is a great example, but by no means the only example. I agree with Eric’s summary and hope to lead ScienceLogic according to these very basic but essential principles. “Let’s be revolutionaries. Let’s take this opportunity, this huge change that is before us with technology and let’s change our businesses, our communication and the way we interact on some new principles that reflect the very best in America.”

ShareThis

The Real ID program is proving to be a veritable sumo match of epic proportions. The calls are going out to kill it before it grows.

From the Baltimore Sun:

“No. Nope. No way.”

So exclaimed Democratic Gov. Brian Schweitzer of Montana when asked whether his state would participate in the federal Real ID program.

Frustration with this misguided, expensive and unworkable federal mandate also compelled another governor, Republican Mark Sanford of South Carolina, to call Real ID “the worst piece of legislation I have seen during the 15 years I have been engaged in the political process.” If Real ID has any friends in the states, they’re not speaking up.

This sentiment is now percolating through the halls of Congress. In recent hearings before the U.S. Senate Homeland Security and Governmental Affairs Committee, senators from both sides of the aisle were blistering in their criticism of Real ID.

Read on.

Article Link

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts and topics.

1. First time this month, my logging polls took #1 spot!  Specifically, a controversial Windows Log Collection Poll (which is a poll #7) sits highest among the Top5 posts (closely behind are poll #6 about logs that people actually look at as well as poll #5 about logging challenges). Poll #8 analysis is coming up tomorrow, BTW...
2. As expected, the post called "Reverse Compliance or "Logs as Proof of Incompetence?"" tops the charts as well. It is about, "reverse compliance", which is a motivation to purposefully avoid technologies that have a chance of telling you that you are NOT in compliance.
3. My quick post on data leak 'prevention' ("In Passing on DLP") is popular as well. Indeed, DLP is a very interesting segment of security market and there is plenty of innovation happening there.
4. ISO17799/27002 might not be hot in the US, but discussing why it is not IS indeed hot. WTH? Well, "Why Is ISO2700x Hot in UK, but Not in US?" is in Top5.
5. Again, people googling for "open source SIEM" have pushed this post (this tiny blurb) to top5. This ancient post from 2 years ago (!) years ago explains why an open source SIEM will NOT emerge soon, if ever.

See you in June!

Possibly related posts / past monthly popular blog round-ups:

• Monthly Blog Round-Up - April 2008  
• Monthly Blog Round-Up - March 2008  
• Monthly Blog Round-Up - February 2008  
• Monthly Blog Round-Up - January 2008  
• Monthly Blog Round-Up - December 2007  
• Monthly Blog Round-Up - November 2007  
• Monthly Blog Round-Up - October 2007  
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007