The first UEPS transaction was performed on Sunday, August 3, 2008, in Baghdad, Iraq, during the official launch of the UEPS smart card technology with the two state banks namely, Rafidain Bank and Rasheed Bank.

The official launch, attended by invitees from Rafidain Bank, Rasheed Bank, the Iraqi Government, War Victim Ministry and Martyrdom Ministry, demonstrated smart card registration, biometric enrolment and issuing of UEPS cards, offline loading of wage payments and government grants to the UEPS cards and dispensing of cash.

The pilot project involving 100,000 beneficiaries is now ready for implementation across selected bank branches and will enable the distribution and payment of government grants to war victims and martyrdom beneficiaries, as well as salary and wage distribution and payment to employees of the two state banks.

Brenda Stewart, Net1 Senior Vice President Sales and Marketing, said, "From the entire team at Net1, we congratulate the Iraqi consortium on this historic achievement and look forward to the successful implementation of the various projects already identified for implementation, as well as the projects currently in business development. Net1 is proud that the development of its core technology, from which it creates end-user products that satisfy the requirements of its customers, can change the way business is conducted leading to the improvement of people's lives. We share the belief of our Iraqi partners that our technology can play a fundamental role in the upliftment of the economy. The success of any technology should be measured, not only by the profits it generates for its inventors, suppliers and users, but also by the difference that it makes to the lives of people," Stewart concluded.

You can read plenty of other blogs about some of the great presentations at Black Hat.  So I thought I would take another angle and talk about some of the other stuff that may be important to you.

1.  secure@microsoft.com – This years hottest party was again the Microsoft party.  This year it was at the LAX club in the Luxor.  As usual there were quite a number of people at the door who thought they could talk their way in or worse yet were told they “were one the list”.  I was happy to be able to go and saw many of the usual suspects there as well. I had to leave the party early to go catch my red eye flight home, so went right to the airport from the party.  As I wrote earlier, Microsoft is trying really hard on security.  But I couldn’t help but notice the irony of this grainy, lousy picture of the DJ booth at the party.  If you can, notice the computers that the secure@microsoft.com DJs are using. That’s right they are Macs!

2. A new low for booth babes – What would a Shimel review of a trade show be without a booth babe rant.  Hey I recognize it is Vegas and all, but EdgeOS went way over the line this year.  A booth babe dressed as a Las Vegas showgirl or some other type of costume makes a statement.  I personally don’t like exploiting woman to make that statement, but I understand.  However, these guys had woman who were dressed so raunchy and classless, that I could not bring myself to post a picture of them.  Come on guys!  You want to resort to the booth babe thing (and BTW I think the Black Hat crowd does not respond to that), at least have a little class.  These girls looked like street walkers and do you and your company no favors.  Is that really the image you want to promote?  Grow up!

3.  The Security Bloggers Network – We are back!  With the end of the Black Hat show, the SBN is going back to being the SBN.  The old logo is back and our promotion with Black Hat is at an end.  However, I want to personally thank so many of you SBN members who blogged about Black Hat.  The Black Hat marketing folks made it a point to come over to me and thank us for the overwhelming support and help of the community.  Our network delivered big time with them and they are already thinking about ways we can work together next year.  I will keep you all posted on that.

We have several new promotions we are working on with the SBN and will have more on that soon. Also, we learned some valuable lessons.  Next time we will work with the network members more closely in doing these affiliations.  Also, for any show like this we need to have an official bloggers get together.  Not because we don’t want to buy our own drinks (thanks to Chris Hoff for doing more than his share in picking up a big bar tab), but frankly we need to reserve a place that has enough space for us.  Security bloggers are big time. We have a great community of people who get together. Lets make it better.

I have some other ideas around the SBN I am working on too and want to form a committee to help. If you are a member and want to get involved, please drop me a line or comment.

Anyway, another year of Black Hat is in the books. It was a good one and I can’t wait until next year!

h8er:  So, how does it feel to work for a company that has made so many bad security decisions.

MSFT guy:  Well, I feel lucky to be in a position to try and influence good security decisions going forward - are there any specifics you want to give me feedback on?

h8er:  All those prompts irritating people, for example.

MSFT guy:  Oh, so you don't like that aspect of UAC.  We've gotten a lot of feedback on that, but the UAC security changes in Windows Vista encompass a pretty wide range of options designed to make it easier for most users to run as non-admin.  Plus, we've incorporated some of the feedback into SP1 and I think it is a lot better.  Have you tried SP1?

h8er:  <crickets chirping in the silence>

MSFT guy: (still trying) Let me ask it a different way.  A lot of folks have said that after the first few weeks, the UAC prompts tapered off, have you not found that to be the case?

h8er:  <crickets chirping in the silence>

MSFT guy: What about some of the other changes in Windows Vista - I think the addition of ASLR, for example, was a good decision and raises the bars for attackers developing exploits.

non-MSFT guys standing nearby:  He has probably never even tried Vista - I bet you run Linux and just heard the prompt stuff second hand.

h8er:  I don't run Linux ... I run a Mac!

(NOTE: This seemed to rattle him, so he went on the offensive.)

h8er:  Don't you feel embarrassed working for Microsoft knowing that 40% of your customers are infected with Malware?

MSFT guy:  Actually, based upon research in the latest Security Intelligence Report, less than 1% of machines have malware and need corrective action - plus, recent research in the same report has shown that most of that is on older platforms and Windows Vista has an even lower incidence.  40% is a pretty high number, what source did you hear that from?

h8er:  <crickets chirping in the silence>

(NOTE:  Need a new tack, better try something different.)

h8er:  Well, I feel a lot safer running my Mac and knowing the malware writers aren't targeting me.

MSFT guy:  Oh, threat landscape is a different topic than the security of the software, but I can't really agree anyway.  Many of the folks I talk to are more concerned about spearphishing or targeted attacks specifically against their valuable data.  Recent data shows that Mac OS X has quite a higher incidence of security vulnerabilities that other comparable systems.  That means that if an attacker did target them, he'd have a lot more options to choose from.  In that case, I feel much more comfortable using or recommending Windows Vista than I would using your Mac.

He left shortly after that, but not before giving the Microsoft guy an invite to his company's party - I won't tell you which company it was, but it makes the story even funnier.  To cap it, a few minutes later, one of the bystanders came by and said "so, did the Mac fanboy get tired of harrassing you and leave?"

Having lots of fun at Black Hat 2008 ~ Jeff

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?

Like most of the service providers we talk to, they look to virtualization to provide immediate benefits to the business – e.g, cost savings from server consolidation and support for Green IT through cutting power/cooling requirements. And one more dimension to virtualization – Opus launched a new service, vClustr, which is a virtual dedicated server that provides the benefits of a fully managed dedicated server at a fraction of the cost…managed by EM7, of course.

We were happy to help Opus by working with them to implement our EM7 solution. Their growth plan was severely limited by inefficient processes and tools. As Opus grew rapidly in 2006, the tools they had in place were not easy to integrate as they were managed independently. There was a manual billing and ticketing infrastructure in place, and valuable engineer time was spent on maintaining what they had instead of enabling business growth. The company faced a choice, either grow by adding overhead and bodies or grow through automation.

Opus chose automation. They needed an automated solution to cover their immediate needs, and also enable them to scale processes for emerging technologies and future service offerings. Throughout their growth, Opus wanted to maintain their “customer first” philosophy and expand their green efforts.

By choosing EM7, Opus was able to replace their multiple, disparate tools with a single, integrated management system for networks, servers, applications, service desk assets and virtualization infrastructure. EM7 provided automated billing, ticketing, alerts and escalation options as well as a branded customer portal for transparency and self-service ticketing.

The results were tremendous. Opus Interactive recouped $130k per year of engineering resources. They automated critical operations to increase efficiency, enabled proactive monitoring and prepared for growth, while giving the business the processes and tools to grow the business without additional human capital resources.

We’re glad that we could help such a great company achieve their goals of providing an efficient “best-in-class” solution that combined superior customer service with a green philosophy.

Get the entire case study here.

ShareThis