Here are some ideas for items you will want to schedule (if applicable):

1. Quarterly Scans (server/application/web testing)
2. Pick an Annual Pen Test date
3. Lay out your calendar of mandatory reporting / testing dates for your company/industry
4. Annual third party security review cycle (external vendors)
5. Annual application testing (internally hosted)
6. IT Controls / InfoSec internal testing
7. Security Awareness training plan for the year
8. Training and Cross Training for your InfoSec Team (focus areas, timing, costs, etc)
9. Annual security policy review
10. Disaster Recovery / Emergency Response planning

And this is just to name the most obvious few… For your company and industry, make sure to check with Internal Audit, Finance & Accounting and your key stakeholders to see what THEY need you to accomplish and participate in during the year.  The better you plan, the more effective you will be throughout the year when it comes time to deliver!

“…TIP will eliminate the requirement for eligible merchants to annually validate their compliance with the PCI Data Security Standard for any year in which at least 75 percent of the merchant’s Visa transactions originate from chip-enabled terminals. “

If a previously PCI audited company could eliminate the need for an externally validated Level 1 ROC (for instance), that could mean significant cost savings.   The good news is that it not only could reduce your audit scope & cost, but Chip & Pin technology significantly increases REAL advantages in credit card protection and fraud prevention.   Worth the read…

http://corporate.visa.com/media-center/press-releases/press1142.jsp

As many articles that have been written on this topic,  you would think that everyone has heard it…. apparently not.   Company help desks and consumer facing corporate associates seem to be none the wiser when it comes to protecting the “High Risk” information of customers, guests and associates than ever.   I have read several studies and blogs recently that all reference the fact that users are still very easily duped into giving up the keys to sensitive data.   In fact, all the bad guys need to do is pretend there is an emergency / computer virus / crisis… whatever… and people seem to bend over backwards to give you their logins, passwords… anything to help!

I could go on and on and give you lot’s of examples of how we still have our work cut out for us as security professionals in educating others but I will keep this short and simple.  KEEP TRAINING.    Educate everyone in your company on the deceptive practices and goals of Social Engineering.  Educate them that just because they don’t have access to Social Security Numbers or Credit Card numbers, that what they DO have access to has value to the BAD GUYS!  Everything is a stepping stone to something else when you are seeking information from an unsuspecting victim!

If everyone would just use the “common sense” that they swear this stuff is during training class in real life, corporate and personal information would be MUCH safer.   Challenge anyone who asks you for anything, verify their identify, have them produce evidence they say who they are and that they have a business need for the information (even if they ARE a company employee!).

As the old saying goes, an ounce of prevention can prevent a pound of cure!

Here is the link from the SANS Internet Storm Center on the “Here You Have” email virus:

We are aware of the “Here you have” malware that is spreading via email.  As we find out more, we’ll update this diary.

Update: 2010-09-09 21:28 UTC (JAC)span style=

via ‘Here You Have’ Email.

A presentation by Russell Kohl (CEO of Freud USA) got me really thinking about protecting intellectual property and what our obligations are to our companies in this space.   I will be digging deeper into this topic and will try to post some of my learning’s in the near future!

Here is a link to the conference:  http://itsecurityleaders.com/southeast/2010/

Here are my quick tips for a successful annual program for third-party vendor analysis:

1. Maintain a Master Third Party Vendor – You better get a good inventory of these vendors, who they are and what sort of information that they store, process or host on behalf of your company.  Chances are the list is much bigger than you think.  Often times “Business” data owners bypass their internal Information Resources department and engage many of these third parties directly. 
2. Obtain Security Checklists/Responses from each Vendor – Once you have your master list, you need to get a basic set of security and information/data related questions answered.   This will help you get your overall risk ratings established and better allow you to prioritize (or avoid) the need for deeper security analysis.
3. Partner with your Vendor Relations, Legal and Business Relationship Owners – The better job you do of establishing a relationship with all areas of your company that help facilitate external relationships where third parties are involved in external technology hosting or processing, then the better position you will be in to perform this work up front, not playing catch up after all the contracts are signed!
4. Root your Analysis in Industry Regulations and Corporate Policy – Do yourself (and your company) a favor and make sure that third parties (excuse me, “Cloud Providers”) can uphold all the regulations and company policies that you expect of your own internal corporate systems.    You can outsource processing, but my guess is if you read the contract, you won’t find that you have NOT outsourced the risk associated with maintaining compliance!
5. Review them Annually! – Make sure that after their initial certification (that hopefully went along with the contracting process), you re-open the checklists at least once a year and get the system owner and third party re-validate the previous answers to your security questions and checklists.   Be aware that your business realationship owners may indeed have contracted for more services that could easily have changed the nature of the data in scope, therfore perhaps changing the risk/classification of the entire relationship!  Also, you may have added security questions to those checklists since the last year that you need new answers for even if the checklists were complete last time you went into them.

Most companies by now have a fairly mature process in place for reviewing and vetting new applications that are usually custom developed or, more likley, a vendor provided COTS (Customized Off The Shelf) application.  These are easy to throw security checklists at, scan the code and the new server and issue your security “pass/fail” analysis in the end.

Not so easy in the brave new Web 2.0 world.   More than likely, you already have new “applications” out there in production you are not aware of.  They probably got there one little webservice at a time that likely did not make the radar of your “new application” security review process.   It reminds me of an old Johnny Cash song about how a factory line worker in a Cadillac plant brought home and built a car one stolen part at a time over the period of many years…

Your best bet is to consider the following and get them in place as soon as possible:

Webservices/SOA Governance:  Put together a webservices governance board that reviews all new webservices and APPROVES them before they are allowed to sneak their way into production.  

Webservices Security Review: Prior to going to your SOA Governance Board for approval, setup a process wherein your security team or application security expert reviews the proposed webservices for vulnerabilities like you would a traditional application.

Webservices Vulnerability Assessment: Go out and research the various available security assessment tools and find one that can scan the types of webservices your company writes.  There are too many to list from open source scanners such as Google’s new Skipfish project to  HP’s mature Application Security Center suite of tools including Webinspect/AMP with all the bells and whistles.

Your best bet to figure out what is going on is to partner closely with your application teams and try to understand the who/what/why/when/where concerning webservices development and go-live at  your shop and begin the process of getting your arms around it from an Information Security perspective!

1) TEST your backup generator.   Sure, you have a big battery backup or generator system, but when is the last time you REALLY tested it?  Schedule an outage, cut the power at your main breaker and see what really happens!  9 times out of 10, something goes wrong.  Servers not configured properly, wiring bypassed (not using the redundant circuit power, etc..).  Better to find out now than later during a real emergency.

2) Update your Business Continuity Plan (BCP) – Where will your associates report to work?  How will they connect to your computer systems, how will you contact them when they are not their desks?  Which systems do you need to recover (what is the Service Level Agreement, aka time to restore service?)  More importantly, even if you have this on file, when is the last time you went over it with a fine tooth comb to review and update it??

3) Execute a Business Continuity Test -  Execute a phone tree test, restore a sampling of your most critical systems, pretend there is an outage… TEST it before it happens for real!

4) Risk Based Approach – While you are updating your traditional BCP, how about talking to your business system owners and data owners to rank and re-order your Continuity and Recovery plans to align better with THEIR needs.  You may be surprised at what you assumed was critical and important to them may have changed in the past year and now something else (you may not even be planning for) is now top of their list!

5) Prepare for your audit – Chances are, none of this stuff is optional.  Why not look at best audit practices for a Business Continuity Audit and be ready ahead of time.

Links:

Audit Guidelines for Business Continuity:

http://www.isaca.org/Template.cfm?Section=Home&Template=/ContentManagement/ContentDisplay.cfm&ContentID=20845

Free Resource Planning Links from HP for Business Continuity:

http://h71028.www7.hp.com/enterprise/us/en/solutions/data-center-transformation-business-continuity-availability.html?jumpid=ex_r163_us/en/sol/eb/solutions_solsbuscontavbl_googlesemaw/&s_kwcid=TC|14803|business%20continuity%20planning||S|p|4527011694

Major releases of the the PCI standard happens in 2 year increments.   For instance, PCI 1.2 was released in October of 2008.   Therefore, you can expect another revision (1.3) or new version (2.0)  in October of 2010!   During this 24 month lifecycle, there are four stages that you should also know about:

Stage 1: Market Implementation (months 0-9) – During this stage (after a major release) this is basically the period where the industry absorbs the standard and the council accepts initial feedback, but there is no formal review process in play.

Stage 2: Feedback Begins (months 10-12) – During this stage, the council accepts market input through a formal feedback process on the current standard.

Stage 3: Feedback Review and Decision (months 13-20) – This is where feedback is analyzed (usually by Technical Working Groups (TWG’s) and determinations are made as to what should be done with these proposed changes.

Stage 4: New Version / Revision and Final Review (months 21-24) – During this phase, the council should produce and release a “summary of changes” document and pick an actual date for the release of the changes proposed (that have been approved).

Stage 5: Discuss New Version / Revision (month 24) – The new revision is discussed at a PCI Community meeting where stakeholders get the opportunity to get more clarification to the new standard / modifications.

For the upcoming release in October, Stage 5 will occur at the next community meeting that is scheduled for September 21, 2010 in Orlando Florida, here is a link to the conference page:  https://www.pcisecuritystandards.org/news_events/events.shtml

There is a catch to getting an invitation to the PCI Community meeting and to be part of the formal revision process to the standard, your company needs to be a community member (Participating Organization).  Annual dues are $2500 per year.   More details about membership can be found here:  https://www.pcisecuritystandards.org/participation/index.shtml

To get more information about the PCI lifecycle, here is a link to a document that explains these stages in much greater detail! https://www.pcisecuritystandards.org/pdfs/OS_PCI_Lifecycle.pdf

My advice to you is this:  If your company is a Level 1 or 2 merchant, your company needs to participate and be an active member in the PCI community.   By being involved and being part of the process, you will not only be better prepared to understand upcoming changes but you may be able to effect them in some way as well!

http://www.authorize.net/support/pafaqs/

http://www.cybersource.com/resources/collateral/pdf/payment_network_mandates/MC_Discover_PartialAuth_Compliance_Mandates_2010_FAQs.pdf