The CodeGuard Blog

I’m in Boston to speak at the Embedded Systems Conference and it will give me a chance to talk about security with a variety of software developers.  Reaching devs and dev managers is important, since they are critical to the success of any security program.  Here are a few of the questions I’ll try to answer:

1. We’ve been writing software for more than 50 years.  Why haven’t we made more progress on the security problem?  Security is one of the most difficult software problems we will face in the next 40 years.  This is primarily because security is not just about telling a computer how to behave.  If it were, we’d have solved it by now.  Instead, security is a constantly changing battle with intelligent humans who are working to break what we have in place today.  If it were just about telling a computer to behave in a specific way, we would be finished by now.  However, we find that there are other smart people trying to defeat any new mechanisms we implement.
2. Why are there so many security bugs in software today?  I believe that security bugs reflect our security development practices of the last 15 years.  Most developers weren’t trained to design or build secure software, so it was easy for them to make mistakes.  That is an education problem.  Additionally, most of our security work has been focused on testing (pen testing, ethical hacking, system security scanning, etc.).  In short we have built an industry around the concept of “penetrate and patch.”  That’s no way to build secure software.
3. What can we do now?  In the US, there’s an old saying that goes “When you’re up to your ass in alligators, it’s hard to remember that you originally came in to drain the swamp.”  In other words, urgent problems often distract you from important problems.  We need to continue killing alligators while we spend time draining the swamp.  In software terms, we should continue testing, since that’s what we are good at.  However, we must also build the long term fundamentals of a strong software security program.  In my talk I will describe four basic steps.  Those steps are:
   1. Assess the security risk of any software you develop
   2. Define a baseline set of security standards that will guide software development inside your organization
   3. Implement security testing for code that could be exposed to attack
   4. Foster a baseline set of professional security skills that are appropriate to the risk level inside your organization

This may be a lot to say in a 1 hour presentation, but awareness is one of the best tools in our arsenal. For most security people, it’s probably not rocket science.  The rocket science will kick in as we translate traditional information security concepts to the world of software development.  Stay tuned.

Jim Molini, CISSP, CSSLP

The Internet turned 40 years old this month. Back on Sept. 2nd, 1969 several people at UCLA began the first test of a networking protocol for the US Department of Defense that would later become ARPANET and then Internet. You can read more about it: (less technical and more technical). The big surprise in this announcement is the fact that most people reading this post can remember a time when long distance communication meant picking up a telephone handset and paying a lot of money. More impressive is the thought that most of us can hardly remember how we managed to live without “the net.”

With the Internet came Internet crime. The first wakeup call for most of us came with the Morris Worm in 1988. In my experience, that worm came closest to shutting down the net – the entire net. At the time I was doing computer security at a government research facility and our best estimate came in at 4000 infected machines, all running SunOS. It took 4 days and a lot of work to correct the problem, but the world moved on and Robert Morris, Jr. honorably paid his debt to society. Oh, those were the good old days.

Today, my own back of the envelope estimate shows that we spend more than $54 billion annually on protecting ourselves from Internet borne threats. The cost in time and aggravation is many times that amount.

So the next time some hacker claims that he is doing something good for the little man by raging against the machine, writing malware, or building rootkits, you can tell him for me that he is also costing the world more than 100 million hours every year that could be used for better things. If the criminals would stop building software to harm the rest of us, I would happily donate 3 hours every year and the money I spend on security software to help make the world a better place. Wouldn’t you?

Jim Molini, CSSLP

I just took one of those online “spot the security bug” challenges they offer here at Microsoft. It was written by Michael Howard and Bryan Sullivan.  You can find it here if you would like to test your knowledge of code security.  I don’t write code for a living, but wondered how I’d stack up against the experts. 

So how did I do?  Uhhh… I didn’t get a zero, but let’s just say that I still have some homework to do if I ever want to work for Michael.

I wondered about that for a while, because I’m really not that bad at security.  I can find a few of my peers who will say I did pretty well writing questions for the CSSLP exam.  So why did I tank this test?  It distracted me for a bit.

Then I went back to look over the questions again and found that many of them were targeted at Web developers.  I’m not complaining about the test.  It’s a great way to raise awareness among the community and I really appreciate the work they did in preparing it.  However, I’m starting to see that some of my skills are becoming stale.  Like some of you who may be reading this, I haven’t been keeping up with the very latest software development technology.  Sure, I still write code in C# or Java.  I still read and write C/C++, but I’m not that clear on the intricacies of Web form injection vulnerabilities.  Never mind Adobe Flash® or Microsoft SilverLight®.

As I started imagining retirement, I thought back to the places I’d worked over the past 10 years.  Most of them still used COBOL for critical business applications.  (That’s good because COBOL was the first programming language I learned.)  All of them had a few servers running Windows NT or Solaris 2.x somewhere on the network because they were unable to upgrade the software.  From that perspective, maybe I can still be of some use to society.  To preserve at least a little bit of my pride, I told myself there were still places around the world that could use my skills.  (BTW, here’s the original Dilbert comic on COBOL and dinosaurs.)

Believe it or not, I expect to see more innovation around software security for legacy apps.  As organizations port more legacy applications to the Web via SOA, source code analysis will become more important for applications written in COBOL and C.  My quick Web search turned up only one tool for analyzing the security of COBOL code.  That came from Fortify Software. 

As I continued to look around, I saw a large open space for software security professionals of every type.  The software world is not monolithic.  We need people who understand Web Services as well as those who are focused on internal apps for corporations.  We also need people who can apply security concepts across a range of software implementations.  As we are seeing throughout the industry, security problems start well before the coding phase.  Poor security requirements lead to poor software security just as poor design leads to a poor implementation.

I’m not saying that anyone can become a software security professional.  If you’ve never written any code, you will spend lots of time learning the craft.  However, it’s also clear that good security goes beyond good code.  Maybe there’s still hope for someone like me.

Back in 2007, I heard a speaker talk about planned updates to an ISO standard.  In his presentation, he indicated that one of his colleagues had asked him to update the ISO standard to include language on “Information Assurance.”  To make a long story short, the ISO standards couldn’t accommodate an update if assurance meant “Security.”  However, too often, we find that entire federal departments say the word “Assurance” when they mean “Security.”  The Defense Department is the worst offender.

Dictionary.com says this:

1. Assurance – a positive declaration intended to give confidence.
2. Security – freedom from danger, risk, etc. 

This problem is almost as old as the Unix operating system.  Back then, some bright people in the intelligence community began using the term “assurance” because a purist engineer told them that no computer could truly be labeled “secure.”  Obviously, this happened in the days before “portable computers” or “Service Oriented Architecture,” but I digress.

Instead of saying “secure systems,” they said “assured systems” (which was a condensation of “security assured systems”) to please the theoreticians and an entire industry grew up to support this thing they call “assurance.”  It was further shortened to “information assurance” at some point in the 1990’s.

Fast forward to the 21^st Century and we find that many aspects of computing must be assured.  Safety assurance is important, as is reliability assurance.  If we travel from “The Beltway” to “The City,” we must stop saying “assurance” and start saying “security.”  If you’re starting to feel like an edge router, you’re not alone.

All of this might be entertaining, if there wasn’t a real underlying problem with the misuse of this term.  It turns out that saying security when we mean security helps us to balance risks.  If assurance only means security assurance, how can we do tradeoffs between security and safety?  Can we ever have safety assurance if every one of our software developers is looking over his or her shoulder at the security group?  Even if we could, could we teach a computer to understand the nuance?

For example, how would you interpret the following business requirement?  “The system must provide high assurance for all valve management safety processes.”  If you read ISO 15226, it means that the safety systems have to work.  If you read the SOAR report or any of the major DoD Assurance directives, it means that your safety systems should not have read up or write down.  These are two fundamentally different things.

So let’s begin reclaiming the language that our global audience understands.  When you want security – say security.

Jim Molini, CISSP, CSSLP

Dan Kaminsky was back at BlackHat this year talking about an SSL hack that would allow a web site to spoof other sites.  He shared the glory for this with Moxie Marlinspike, who also identified the same vulnerability.  The hack was an interesting attack, not against the design of SSL, but against the coding of certain SSL implementations.

The vulnerability is demonstrated by placing “\0” into a URL used to identify a subdomain.  Since some browsers translated “\0” into a single character (ASCII zero), some browsers failed to fully qualify the domain name of the site.  While looking into the problem, I originally wondered why any system would let you insert null characters into the name.  RFC 3986 says the following:

As a result, a common security concern for server implementations that handle a URI, either as a whole or split into separate components, is proper interpretation of the octet data represented by the characters and percent-encodings within that URI.

It went on to say that the ‘\’ character should be handled with care, along with things like: ‘/’, ‘.’, ‘..’, and others. That made sense.  The fact that someone strung together the characters ‘\’ and ‘0’ should not have made any difference when the URL was processed by the browser.  Although nothing should have happened, it apparently did in certain browsers.  It could have happened when the parsing algorithm passed the byte sequence off to a routine that reprocessed the characters according to standard C/C++ tokenizing rules.  This is a classic coding error that exposes an underlying vulnerability.  Your attempt to correctly implement a standard syntax is obstructed by the tools you use.  It’s also notoriously difficult to spot in any type of code review.

Now, you may ask, did this really represent a coding error or should they have specified the syntax of URLs to exclude ambiguous interpretations.  We see many crypto standards specifying rules to prevent ambiguity, should it have happened here?  Before you answer, remember that these standards must be interpreted for both English language sites and those that use alternate character sets.  I’m interested in hearing what you think.

Jim Molini, CISSP, CSSLP

In words that may go down in history, on July 6, 2009, U.S. District Court Judge Richard Jones wrote: “In order for ‘personally identifiable information’ to be personally identifiable, it must identify a person. But an IP address identifies a computer,” An overview of the ruling is here.

This ruling dismissed a case by certain people against Microsoft, claiming that Microsoft’s recording of their IP addresses constituted a violation of Microsoft’s End User License Agreement or EULA.  The plaintiffs claimed that a user’s IP is personally identifiable.  Microsoft, claimed otherwise.  In this case, the judge agreed that an IP is not PII.  That’s a good thing for all of us in the security business, but it’s also the right logical conclusion at this time in history.  Here’s why.

1. IP addresses are assigned by ISPs.  They are not assigned by end users.  Most computers only obtain a lease on an IP address for days or hours.  As such, the IP address is often just a temporary association between a computer and the Internet.  It’s not the same as the relationship between a user and the user’s computer.
2. You can’t buy an IP address, you can only lease one.  In this regard, it is not “property” as would be defined in many legal circles.
3. IP addresses are easily computed and many attack programs generate IP addresses randomly and attempt to connect to those addresses.  If you look up a specific IP address via reverse DNS, you can associate it with a domain, but users can also mask their personal information in the domain record – if they work through an ISP or other representative.  If IP addresses are considered PII, it will destroy the long term viability of DNS.
4. Finally, the Internet is not a government owned or regulated entity, as are the phone companies in many parts of the world.  Although certain governments may choose to limit use of the Internet as a matter of national policy, those regulations would not and should not apply across national borders.  In short, they can’t tell the Internet what to do.  The Internet is flat and those who would unflatten it are swimming upstream. Just ask people who want to tax Internet sales.

There are other issues, but I think you get the idea. 

Of course, this means that I think the EU made a mistake when they required ISPs to restrict access to IP information.  It is harming the competitiveness of IT companies over there.  If you disagree, let me know why.  I’m interested in your opinion.

Jim Molini, CISSP, CSSLP

One of the projects I’ve been working on recently is to prepare a reading list for software security professionals.  Over the years it has become increasingly difficult to find the right reference papers on topics that should be of interest to all of us.  The hardest paper to find is the paper that described the original Clark – Wilson integrity model.  However, after 5 years of searching, I found it and uploaded it to the Papers directory here on the site.  You can download here from this site.

I tracked down the Clark-Wilson paper precisely because it was so difficult to find.  It was presented in 1987, the year before the IEEE began storing Security & Privacy conference proceedings online.  Therefore, it was relatively easy to find Brewer Nash (published in 1988), but almost impossible to find Clark Wilson.  Even the references to the paper are missing data that you can only find in their original text.  Other integrity models are available through other channels, but I had never seen a source on the Internet for this specific document.  So I finally found a copy at Stony Brook University in New York and uploaded it as a service to the community. 

Why?

I think that this model is important for a few reasons.  First, Clark-Wilson is one of the early models that successfully described a workable approach to data integrity.  I was not impressed with Bibabecause it appeared to merely rehash Bell-LaPadula, replacing disclosure with integrity.  I did not see in Biba the specialized attention that integrity controls required.  Brewer-Nash (aka “Chinese Wall”) was a good paper, but still relied on users to control their own actions.  Clark-Wilson, however, seems to work without special “struts.”  It is also most compatible with modern object oriented systems, IMO. 

In a well formed OO system, data transformation is bound to the entity that hosts the data.  This is compatible with the concept of the Transformation Procedure.  Moreover, the concept of a Constrained Data Item can be implemented through a variety of object interface management methods, like getters and setters.  So Clark-Wilson gets my vote for best integrity model from the early offerings.  There have been improvements.  I’ll talk about them in a future post.

Until then, look through the model.  Think about how it could improve the quality of your system.  Then post a comment to let me know if you agree or not.  I’d be interested to hear your perspectives. 

Jim Molini, CISSP, CSSLP

File this one under the heading “No Good Security Deed Goes Unpunished.”  This week, the Wall Street Journal reported on a former Vice President at Goldman Sachs who was arrested by the FBI for allegedly stealing source code from his former employer.  You’ll find a detailed description of the circumstances and possible impacts by Tyler Durden on the Zero Hedge web site.

If all the allegations are true, Sergey, who managed a software development group in the program trading business for the Goldman Sachs, apparently decided to steal some of the software that makes it work.  Whether this is Goldman’s “magic sauce” for trading or not, is beside the point right now.  Here’s what I can see from the recent media reports:

Sergey worked for Goldman in their VP of Equity Strategy, according to information uncovered by  Zero Hedge.  According to the affidavit sworn out against him, Sergey downloaded 32 MB of source code from his company, within 5 days of leaving for another firm.  BTW, the other firm was apparently willing to triple his salary for making the move.  About a month later, he was arrested while returning from Europe and charged with stealing the software. 

To a computer security guy, this would say that Goldman Sachs had a program in place to detect and report unauthorized transfers of certain software components.  This is a good thing, right?  Moreover, the response team was good enough to identify a potential theft and run it through channels until an arrest warrant had been prepared and served by the FBI.  All of this happened in less than a month.  That’s great security work.  How many other firms would have been able to find and track this kind of event at all?

Unfortunately, other reports have focused on many of the possible negatives for Goldman.  That’s too bad.   This was a classic bit of investigative and response work at a major financial institution and it may have prevented important software from falling into the wrong hands.  If nothing else, it has sent a great message to everyone who develops software at the firm.  The message is, “We will protect your intellectual investment in our success.”  My advice is to gut it out while the world gets used to a company who will protect all assets.  So my hat’s off to Goldman Sachs.  Hopefully, after all the legal wrangling is over, they can tell us how they did it.

 Jim Molini, CISSP, CSSLP

If you develop software under contract to another organization, you will probably find that you must create a security development lifecycle (SDL) that is different than the in-house model I discussed last week.  Security under contract includes custom software development work done by local, as well as offshore software development houses for customers.  This is how we developed software for the US Space Program and how many large organizations develop or maintain their critical applications.  Developing software for someone else means that you must meet their standards, regardless of your own expectations.  If you fail to meet their minimum standards, you may open yourself to legal liability.  If you exceed their expectations, you may find that you are underbid by another development shop for future work.  How do you reach the right balance?

First you must understand the client’s perspective on software security.  Are they risk tolerant or risk averse?  Do they know enough to be concerned about the possible vulnerabilities in the application you are developing?  Clients often tip their hands about risk tolerance in their initial request for proposal (RFP).  Read the entire RFP and look for broad statements about security.  Even if the requirements section is thin, you may find that the policy section mandates more security than the specification does.  If you see this, you know that you will have to ask additional questions.  This is also a good time to educate your client on the specifics of software development security.  Explain the risk of poor application security and the cost of building security in.

You will demonstrate the added value of your SDL in your proposal.  If you’re already under contract, talk about it anyway.  Be sure to show how you can improve the security of your work at a reasonable cost.  If you can’t be accurate in your cost estimation process, your SDL and your project will fail.  It’s that simple.  Your SDL should be efficient and based on a known standard.  Clients like it when contractors adhere to independent standards so you should be able to favorably compare your operations to those of other well-known organizations.  In that regard, your CSSLP certification should help you to establish your own credibility.

Doing security under contract means that you will spend more time tuning security requirements.  Get this right or you will pay for it later.  I still remember a government contractor who delivered an unusable application and then blamed it on the customer, saying, “You didn’t provide us with any performance requirements.”  In my opinion, this type of behavior borders on professional negligence.  If you fail to ask about security requirements and fail to provide feedback on the impacts of those requirements, you should not expect much repeat business.  If, however, you ask about security requirements, explain the risk and are told that your client cannot afford the kind of security you offer, define a set that is affordable until both sides understand both the risk and the cost.

Once you have estimated the cost of security, it’s your job to make sure that you can effectively deliver the level of control that your client has specified.  Good security design makes all the difference here.  Security under contract means that you should optimize your security mechanisms to the client’s environment.  Build to their authentication system.  Report in a way that is compatible with their auditing standard.  Work with their access control system where possible.  If you build your software for multiple clients, abstract these interfaces into an API.  Doing these things will dramatically improve the psychological acceptability of your system and is often something that they are willing to pay for.

You should build your security mechanisms with the expectation that they will be used and tested by a third party.  This is a common feature of many government software projects and you have to be ready for it.  It’s harder because a third party may not use the software as you intended it.  This will add time to the delivery phase of your application.

Finally, consider security during the system maintenance cycle.  Document your security features well and show how the security of the application can be upgraded to stay compatible with evolving technology.  If you do things right, you may find yourself under contract for 10 or 15 years.  This is not unusual for large contract jobs.  However, if you do security poorly, you may find yourself replaced because you don’t have the necessary differentiators to be considered a long-term partner.

The other major delivery model addresses security for Independent Software Vendors (ISVs).  ISVs require the most sophisticated and diverse model for an SDL.  It’s impossible to address that model in a blog, so I’ll move onto other topics unless I hear of interest from you, the readers.

Jim Molini, CISSP, CSSLP

As the field of software security emerges, you will see many people telling you about “the best way” to do security for your organization.  Some of the advice will be very good, but it must also track with your development model.  If you do in-house software development, you come up with a different security design that someone working at a large commercial software developer.  If you develop under contract to another entity (I call this Development For Hire), you may have your own security lifecycle as well.  Today we’ll talk about in-house development.

In House – This kind of software is focused on small teams (relatively) doing work for a specific deployment environment.  You can rely on the fact that your installation has a certain number of deployment parameters.  The software might run on a single mainframe, or on PC’s configured with the organizational configuration.  This simplifies much of your security planning and also reduces the attack surface of the applications you build.  Even if you use the same steps in the lifecycle, you will find that you will make different decisions than other software developers about your security.

You may also find that you can depend on the organization (company or government agency) to custom configure the server hosting your application, to further reduce risk.  Additionally, these apps often operate within a single authentication and user provisioning environment.  All of these controls simplify the security design as you go through development.  If this is the case, you can focus more of your security effort on broadening the reach of security mechanisms and on improving the acceptability of security features.

The down side of in-house development models is that you often have fewer people working on security.  Developer time can be precious as more diverse effort is expected from fewer people.  In that case, you may find that security training is as important as good security design.  Make sure that the developers in your organization can get the knowledge they need quickly and efficiently. 

Another problem you may experience is the problem of legacy controls.  You may have to figure out how to apply security in a shop that uses COBOL for most critical apps.  If that’s the case, don’t despair.  COBOL is not as easy to exploit as software built in C or C++.  Furthermore, as a more verbose and procedural language, it is often easier to spot problems in COBOL than in some of the more modern languages.  If you use COBOL, you may need to implement peer code reviews for security instead of using a static analysis tool.  I’ve heard of a static analysis tool for COBOL, but haven’t had the chance to look it over.  If you have, send me an email and let me know what you think.

As you can see, in-house development carries its own challenges and opportunities.  Even if you only have one part time specialist, you can improve the security of software you develop.  Good luck.

Next week, I’ll talk about software for hire.

Jim Molini, CISSP, CSSLP

President Obama touted the new U.S. plan for Cybersecurity.  (Cybersecurity is the US government’s term for computer and information security these days.)  The new proposal is based on a Policy Review conducted by the administration and has several important changes for anyone who thinks about security from a global perspective.  In some ways, the bland “bureaucratese” hides a major change in U.S. policy toward the Internet.  Be prepared.

First, this document changes the game in privacy.  The new approach offered by the Obama administration places privacy as a distinct element of the new universal policy.  Notice how the document discussed privacy and tried to reframe the discussion of network monitoring.  It might not be a huge change for many of the federal agencies that deal with information today, but this will begin a major shift in American industry.  My three-word analysis for the IT community in the U.S. is:  “Expect More Offshoring.”

Most U.S. companies have enjoyed a competitive legal advantage over European firms when operating in a privacy-sensitive environment.  Our current laws are not tuned to fully protect the private data of individuals, so US companies had more flexibility in defining the protections for individual privacy.  That will change, if not through legislation, probably through the courts.  This will mean that many companies could end up radically changing the way they handle customer or visitor data.  It is not necessary, but many business people may opt to take the easy way out.

Second, we are finding that the world really is flat.  That could make offshoring a kind of protection against civil suits.  If companies find that offshore firms provide insulation from civil suits, you will see an avalanche in offshore data processing and outsourced jobs.  Add in the new taxes being proposed by the administration and it could make a perfect storm for IT offshoring.

If you’re a US software developer, there are a few things you might do to keep your work closer to home.  First, learn how to develop for a privacy-focused service.  Find an expert to help with the basic policy and tune it to the needs of your organization.  Think about whether you want to be aggressive or conservative in your privacy protection for site visitors.  Privacy is not a switch.  You have many options.

Eliminate unnecessary data and reduce the amount of information you collect from users.  A good way to start is to use federated authentication, like Windows Live ID, or OpenID.  These offerings give you only what you need and reduce your need to protect authentication data.  If you inventory the PII stored by your site, you may find that much of it is required just for authentication purposes.  Why take that risk?

Think about your monitoring options.  If you have a promiscuous network intrusion detection system (NIDS) on your site, you may be collecting too much personal data.  Tune down what you keep and “anonymize” the rest.

Next, consider how you will protect any Personally Identifiable Information (PII) that you do collect.  If you are out to create a community, it’s not necessary to know everything about every member.  Finally, start working on the design changes necessary to reflect an adequate privacy policy.  You will improve your image and your  sessions per unique visitor if you have a respectable privacy policy.  It’s not easy, but it is likely to be important in the next two to three years.

Jim Molini, CISSP, CSSLP

No, this is not the beginning – or the end.  However, it really is the end of the beginning.

After more than 35 years of industry research and more than two years of development, we are finally beginning to see software security emerge as a distinct profession.  This is very cool.  The newest manifestation of growth in software security is a professional certification called the Certified Secure Software Lifecycle Professional, or CSSLP.  It’s being offered by (ISC)², a name that many people already know.  I’m a member of the (ISC) ² Advisory Board of the Americas and they list me as a primary architect of the cert.

Don’t get me wrong.  We didn’t invent the concept of software security.  The credit for that goes back to the early 1970s (more here).  But now, there is a real, independent organization that will test and certify your skills as a software lifecycle security professional.  If you don’t know what I’m talking about, here’s the 101.

(ISC)² has been certifying the professional qualifications of information security people for almost 20 years.  The Certified Information Systems Security Professional (CISSP) certification is the most common internationally recognized cert for people who specialize in computer security work.  Now they have released the CSSLP for people who specialize in software security.

Big Deal.  Right?  No, really.  This is important.  I know that a lot of people will be skeptical about this whole thing, but it’s time to finally recognize the people who know how to make software more secure.  A lot of people go through life every day doing the job of “security guy” on a software project, but they get no tangible recognition for their specialized skills. If you are one of those people, you might wonder if you really know enough to be considered a “professional.”  Now, you can see what other experts in the field say about software security.  You can test your skills against a common body of knowledge.  If you want, you can get certified.  This also means that your employer will have tangible proof that you measure up with other experts in this field.  In this game, everyone wins.

That’s why I say that this is the end of the beginning.  From now on, if you do security in a software house, you can measure your skills against a standard.  If you talk to people about the development of secure software, you can verify your advice against the standards established for the industry.  If you test the security of applications, you can measure your own development against a professional standard.  Last year anybody could claim to be a software security expert.  Now we have a measuring stick.  It’s not perfect.  Nothing is at this early date in the lifecycle. But it’s a start.

If you work in the field of software development, this is also an opportunity for you to get recognized.  In fact, this is one of the primary reasons behind all of the work.  We (the volunteers behind the CSSLP) want you to be recognized for all the hard work you do. It’s not easy being the security guy.  You have to learn software skills and then learn security on top of all that.  You have to influence people to do extra work to avoid problems that might never occur.  However, you also have to keep the project on schedule and under budget.  All of this takes a special skill and you should be recognized for that skill.

At the same time, software security is a journey, not a destination.  So this blog is intended to help you navigate the professional hurdles you will face in your journey and to get you thinking.

Software security is still new.  The best techniques are still being imagined.  If you do this for a living, you certainly know that there is plenty of room for improvement.  Let’s start figuring it out now and move the industry along with us.  Good luck in your career and write to me if you have ideas about what I should discuss in a future post of the CodeGuard Blog.

Jim Molini, CISSP, CSSLP