That’s all good, right? Enterprises are focused on keeping these devices secure. It’s good as long as it doesn’t distract efforts from the truly inherent risks of mobile computing – and that has little to do with the device itself and everything to do with what happens within it.

While mobile device management and the inherent security of device operating systems are important, they’re most certainly not the entire story. Most organizations are extending their websites and web applications so that they can be accessed via mobile browsers and apps. And therein lies a tremendous amount of risk that isn’t being discussed surrounding these applications, the data they manage, and the servers that support them. I think the BYOD discussion largely overshadows these risks.

In one of our more recent engagements, we collaborated with a company that helps to process insurance payments on mobile devices. The use case was that users would take snapshots of the bill and then it would be uploaded to the insurance processor. In this case, as is true whenever intellectual property, financial information, or regulated data is used, it’s crucial to go beyond the operating system and the device. We looked at how the application functioned and communicated with the processor. We examined how the photos were protected. And we evaluated how well all of this was architected together. Because the client certainly didn’t want someone to lose their cell phone only to discover that the photos of medical treatments and receipts and any other protected health information was available in the clear on the device.

This is just one example, and most enterprises have no shortage of new use cases regarding how they want to leverage mobile. Yet, mobile devices require a different security strategy to ensure existing security policies and regulatory compliance mandates are adhered. Many of these devices don’t have security controls in place – such as anti-malware and data loss prevention. And, what’s possibly much riskier – many enterprises haven’t secured the server infrastructure these devices connect to. All of this risk can expose an organization to significant liability from a data breach.

By taking the time to conduct a mobile application security assessment, enterprises can learn what they need to know to tackle complex technical challenges.

And it’s important to not only understand what technical controls and secure application development practices are in place for the device itself, but also how security controls can protect data from the device through to the back-end or cloud-based systems it connects.

For the device, one would look at such attack vectors as GPS data, malware infection possibilities, application vulnerabilities, browser exploits, how APIs may be gamed, Bluetooth connections, and many others. It’s always a good idea to look for ways to reduce the attack surface of the device and the app. This can include code signing and app store approval processes, sandboxing to limit attacker movements, employing memory protections, and leveraging encryption. One area enterprises tend to overlook is their web services security. How well are the Internet-facing servers, applications, APIs, and web services secured before they even reach users’ mobile devices.

It’s important to note that this advice pertains to custom apps and mobile architectures built in-house and those that have been outsourced – you can’t just trust that the developer’s practices were sound because they were detailed in the contract.

Finally, it’s important to say that rarely should security concerns be a reason to delay or skip mobile efforts. It is security’s role to help bring these ideas to market quickly in a way that reduces your organizational risk.

# # #

Hope to see everyone again next year!

BSides is a group that creates events for (and by) the information security community. This group supports pushing information security conversations into new realms, as well as creates opportunities for those within the community to share ideas. The event involves a day of presentations on a number of topics regarding mobile and internet security, as well as networking opportunities. At WireHarbor Security we strive to push limits and work to support the information security community as much as possible–which is why we’re so excited to partake in this great event! Please stop by our booth and say hi if you’re attending.

Want to go, but don’t have tickets?

Here’s how. Follow us on Twitter at @WireHarbor, and tweet why you want to attend @BsidesChicago. Be sure to include both the @WireHarbor and @BSidesChicago handle! We’ll pick two people to join us at the event and announce them via our Twitter feed by end of day, Thursday April 25^th. Hope to see you there!

Where:

Abbey Pub

3420 W Grace Ave

Chicago, IL  60615

More Information:

http://www.securitybsides.com/w/page/60569695/BSidesChicago-2013

To help improve security spending, and overall security, there’s been a lot of discussion around applying big data and analytics to security. Consider the expected growth of big data investments, which is currently $5 billion and expected to increase to $50 billion by 2017. A not insignificant amount of this money will be spent on IT security efforts. And, I can tell you, based on what many companies are doing with data today, much of that investment will be misplaced and misspent.

Why? Too many enterprises measure the wrong things. They concentrate on things simply because they can count or measure them, such as how many port scans they see or how many spam e-mails they block. Do these measurements matter a lot? Probably not. To truly improve their security and get the most value from their efforts, it’s time that organizations focus more on the things that matter and that will have the most positive impact on the security posture of the organization—and not just doing things to look busy.

What must be done first is find ways to fully utilize the information you already are collecting, and that requires putting in place an information management strategy that will examine what information sources are available in the environment and what systems and devices may already be recording security events.

This will include not only security devices, such as firewalls, anti-malware software, and intrusion-detection systems, but also traditional application, server, and networking gear logs. Take a close look at what data you are collecting, what data you could be collecting that you are overlooking, and how you are reporting and analyzing these data?

For example, imagine you are trying to determine how certain security investments have improved organizational productivity. There are a number of things you could look at with this objective in mind, one of which would be malware infections. While it’s good to know that you are blocking 5,000 viruses a day, it’s better to know what that means as far as business impact. That information could be gained by comparing blocked viruses with your help desk support analytics? As the number of viruses you are blocking increases, it’s likely that support calls decrease, and so will productivity loss due to malware infections. Now you are turning data into information.

Another example would be failed application log-on attempts and password reset requests. For instance, if your organization was enduring several hundred failed log-on attempts a day and dozens of password reset requests (due to employees forgetting passwords to apps they don’t use very frequently), the costs from lost productivity and support expenses can add up quickly. By tracking this, and comparing the savings of reduced authentication failures that could be attained by deploying single sign-on software, you may find all of the budget you need for that single sign-on deployment.

Many companies we work with are trying to glean that kind of insight; however, they often get bogged down in the weeds. They spin their wheels arguing over what specific algorithms they should use and how results should be calculated—and tend to overcomplicate matters. It’s important, especially initially, to keep it simple and to identify the key data that need to be analyzed and how they relate to the business. I can’t stress this point enough. Even companies that are working on merely classifying their assets take a trip down the rabbit hole and spend years trying to classify what specific role a particular server provides rather than performing a loose classification.

Keep your analytics gathering as simple as you can and focus on what data you should be collecting, what data you are currently collecting, and how, based on that information, security correlates to actual business need. Then, build your security data and analytics program out from there.

It’s also worth noting that if you haven’t deployed a Security Information and Event Management (SIEM) application yet, these are great exercises to do beforehand. Understanding your environment, what data you are collecting, what information you can gleaned from them, and what additional insight you need are keys to understanding before you deploy a SIEM.

Unfortunately, that’s precisely the opposite of what many companies do when they deploy a SIEM. Most simply implement the SIEM to collect massive amounts of data and they don’t take the additional – and vital – step to see how these data relate to their business strategy. This way, instead of just seeing that the number of security alerts grew from 3.5 million last year to 4.5 million this year, you’ll have a better idea of what alerts are important to focus on, what security investments have made a solid financial impact, what controls are working, and which are not. At the end of the day it’s not about data for data’s sake (even Big Data)—it’s about having the right insight. And that starts with making the most of the basics and building intelligently from there.

# # #

Now, more than 140 years later, another new beginning has emerged in the Information Technology community of Chicago, and WireHarbor Security, Inc is proud to be a part of it. Starting in 2013, WireHarbor Security has been accepted to join a select group of other great technology companies in the 1871 space of Merchandise Mart, located in the heart of the downtown Chicago loop area.

Many great companies have already seen tremendous growth as a part of this ecosystem of Technology and Entrepreneurism and WireHarbor Security hopes to join the many leaders of the IT community who are challenging the way we look at digital commerce, information and business in this exciting digital age.

Our new offices are located at:

222 Merchandise Mart Plaza
Suite 1212
Chicago, IL 60654

Please feel free to contact us for a complimentary tour…

This post will highlight key things to consider about building security into the development lifecycle in manageable steps – while also embracing rapid development cycles. We see a lot of this in our practice, specifically around rapid development cycles. Many of our clients ask us how they can best manage agile development cycles because they have such quick sprints. And even if you have two week sprints, you have to make sure security is somewhere in the process. You can’t wait until the end of the development lifecycle and then expect to bake security back in.

The Problem

When organizations try to employ legacy waterfall testing methods to agile development, they often find it just doesn’t work. With Agile, you need to understand how to simplify bits and pieces of security testing.

One of the things we try to show clients is how to automate code segment testing, so they can identify dangerous code segments as it’s being developed. Even learning how to integrate a minimal level of testing in one’s Secure Software Development Lifecycle (SSDLC) can go a long way into improving the security of the code developed in these sprints.

Security awareness is Important

We are working with companies right now to train their developers on secure coding fundamentals. They want that training and awareness in the minds of developer’s as they are writing code. Essentially, it’s a matter of having the tools in place and using them consistently with each sprint, as well as providing security awareness training with the developers and providing them access to the resources and support they need should they get stuck.

One of the biggest hurdles is for developers to learn how to incorporate these steps in parallel, rather than thinking of security as something that is separate from QA and development. This is something that takes time, practice, and discipline. It may slow down the initial number of cycles, but over time it saves time and money by catching smaller mistakes early and often. That is really the point you want to get to: killing the pain upfront, rather than pushing it into the future where it grows much worse and bigger.

This integrating security into rapid development cycles is exactly what our Secure SDLC Program Design services are designed to do and should be something companies consider. An outsider, for instance, brings a broad perspective from the best practices they’ve learned from other companies, and they’ll also helped different organizations overcome many different types of SSDLC challenges. So bringing in the right consulting team, from time to time, is certainly something to consider.

The Future of your Software Quality

The important thing is to realize that if you are not updating your application security efforts to match changing development methods, your program is going to slip and you risk generating a considerable amount of insecure code very quickly. But through training, use of the right tools, and smart outside help there’s no reason speed or innovation need suffer for security. And, conversely, there’s no need security has to suffer for innovation and speed.

While the vast majority of enterprises don’t suffer glitches that traumatic, they certainly do suffer business losses from poor software quality. This can be in the form of lost sales, lost eCommerce transactions, downtime, damaged brand, and of course in the case of security related defects, a serious data breach.

And, as you’ll see in this post, there are many ways businesses suffer losses due to low software quality.

Surprisingly, most are not aware of the significant costs associated with software defects. Software quality costs extend well beyond the investments made to buy, develop, or maintain the application itself; these expenses also extend beyond the value of data when it unintentionally leaves your network, either by accident or malice. And the more testing you put into your software, the more value you will get from that software. The fact is that the more reliable and bug-free your software, the more agile, cost-effective, and efficient your business will be.

This post explains the powerful business case to build secure and sustainable software, and the heavy cost of not doing so.

The reality is that poorly designed and developed software is fragile. In our engagements, we have seen companies reach a point at which their software became so fragile that they don’t dare to touch it. They don’t upgrade it. They build everything around it when they need new functionality. What they end up with is a very brittle layer of applications that nobody in the business will touch out of fear of something breaking without an easy way to fix it. This obviously limits how quickly, and successfully, a company in that circumstance can grow.

This loss of agility is a very serious problem for large companies. They get stuck with a lot of antiquated and cumbersome technology at a time when they face serious challenges from startup companies that threaten their market position with new, disruptive technology. And, because of their brittle software, they often can’t move as fast as their smaller competitors. Many large companies have legitimate concerns about scrappy startups launching from a small office or garage and posing serious challenges to their market share. Yet, the fact is that one of a company’s best defenses against that outcome is to have agile applications and business-technology systems that can respond quickly, and nimbly, to both changing market conditions and such competitive challenges.

Additionally, we’ve recently seen many security issues arise from applications that were never designed to be released into a worldwide market. These applications then start receiving inputs that were not conceived of by a developer, who was thinking regionally in the initial design.

We’ve also witnessed poor software quality affect acquisition valuations – and not positively. One of the services we provide to acquiring companies is to assess the quality of the applications they may be buying along with the business. After all, poorly designed and rigid software can lead to a potential money pit for the acquiring company. Considering the situation, it could have to invest considerably to remedy software bugs and attempt to integrate such brittle systems into its own.

This can add years to the time of potential profitability acquisition, if the integration of the businesses was otherwise relatively smooth. In fact, we’ve seen business deals that have looked very good on paper – at first. However, after 18 months to two years into the integration, the new business is decimated by software integration costs that arise because there was not enough due diligence on that aspect of the deal.

There are other costs to consider, as well, including damage to one’s reputation and the direct costs associated with data breaches. In an extreme example, Sony itself estimated direct costs of about $171 million after it suffered a series of data breaches. In its most recent study, the Ponemon Institute estimates that the cost per record in a data breach is $214, and averaged $7.2 million per data breach event.

Most of these costly challenges associated with poor software quality – decreased agility and competitiveness, brittle IT systems, damaged brand, and costly data breaches – can be avoided (or greatly mitigated) by developing code that is robust, that has been thoroughly tested, and ideally has security and quality checks integrated within the development process.

In summary, there are many reasons why poor software quality proves costly to business:

• Security breaches are costly. In its most recent study, the Ponemon Institute estimated that the cost per record in a data breach is $214, and averaged $7.2 million per data breach event.
• Vulnerabilities and quality issues are more expensive later. It’s often much more costly to fix vulnerabilities after they are in applications that are in production. To save on associated development costs, fix quality issues prior to an application’s release, where they can be fixed quickly without major application overhaul or downtime.
• Bad software hurts business valuation. As we noted above, one of the services we provide to companies  considering an acquisition or merger is to assess the quality of the applications they may be buying along with the business. Poor software quality means costly integration and additional development costs that can make acquisitions very costly.
• Poorly designed software makes a fragile business. Bad software is risky to touch for any reason. When deficient software is layered on top of more deficient software the infrastructure becomes so fragile that it never b handled. No upgrades and everything is built around these applications when they need new functionality.

Therefore, quality software provides for a more agile business.  As we’ve shown above, the more reliable and bug-free your software, the more agile, cost-effective, and efficient your business will be.

In our next post, we will show why developing secure and sustainable applications does not have to negatively affect the speed of development, or business agility, as so many assume it must.

A big story today from Threatpost and an unfortunate blow to the Ruby on Rails security community. They are announcing that all current versions of Rails are vulnerable to a SQL Injection flaw. The issue is caused due to flaws in ActiveRecord  and its handling of dynamic parameters. Users of the Rails frameworks are highly encouraged to update to the latest version immediately to prevent potential access to sensitive data by a third-party.

Threatpost reports:

All of the current versions of the Ruby on Rails Web framework have a SQL injection vulnerability that could allow an attacker to inject code into Web applications. The vulnerability is a serious one given the widespread use of the popular framework for developing Web apps, and the maintainers of Ruby on Rails have released new versions that fixes the flaw, versions 3.2.10, 3.1.9 and 3.0.18

Like most web frameworks, Ruby on Rails has had its share of security mishaps. A famed encounter was the Ruby/Github mass-assignment debacle in March of 2012.

This most recent issue discovery is credited to Phenoelit. The Ruby on Rails maintainers response can be found here.

To see if your application is vulnerable:

1. Check your Gemfile for versions lower than: 3.2.10, 3.1.9 and 3.0.18

   gem 'rails', '3.2.10'

2. For those running Webrick, you may also view the startup config, as such:

   => Booting WEBrick
   => Rails 3.2.10 application starting in development on http://0.0.0.0:3000
   => Call with -d to detach
   => Ctrl-C to shutdown server
   [2013-01-03 14:21:06] INFO WEBrick 1.3.1
   [2013-01-03 14:21:06] INFO ruby 1.9.3 (2012-04-20) [x86_64-darwin11.4.2]
   [2013-01-03 14:21:06] INFO WEBrick::HTTPServer#start: pid=51175 port=3000

To update to a current version from the command line, choose the appropriate branch version and run “bundle install”

NSString *name = [[NSUserDefaults standardUserDefaults] stringForKey:USERNAME];

This is an example of bad coding practice when used with a sensitive bit of data. The reason it is considered bad is because the NSUserDefaults() routine stores this information in a plain-text property list or plist file. These files can be easily read and are weakly protected from a potential attacker.

The iOS developer libraries contain a number of security APIs that developers are able to take advantage of. Keychain Services are one of the protections that allow for secure storage of sensitive application information.

Below is a very simple example of storing data in the keychain:

NSMutableDictionary *dict = [NSMutableDictionary dictionary];

[dict setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass];
[dict setObject:account forKey:(id)kSecAttrAccount];
[dict setObject:(id)kSecAttrAccessibleWhenUnlocked forKey:(id)kSecAttrAccessible];
[dict setObject:password forKey:(id)kSecValueData];

<code>OSStatus error = SecItemAdd((CFDictionaryRef)dict, NULL);

A good practice when developing mobile applications is to store as little information on the device as possible – after all, a great way of ensuring information is protected is to prevent it from ever passing through the intruders hands to begin with. By minimizing the latent data stored on the device and creating lightweight clients that funnel data back to server-based solutions for processing, we can be assured we have minimized the exposure of that data to an adversary.

A spokesman for the stock exchange confirmed the report…

“[A] bug caused the system to react in an unexpected way for one specific index futures order category that resulted in the system treating this order as a negative quantity (i.e. with a minus sign in front of it),” he said, explaining that the correct order was a much lower figure.

Integer Conversion

According to information provided by the exchange, these problems were a result of a single instance of a class of common software bugs named Integer Sign Conversion. The following description from Wikipedia illustrates the issue nicely:

“In some situations, a program may make the assumption that a variable always contains a positive value. If the variable has a signed integer type, an overflow can cause its value to wrap and become negative. This overflow violates the program’s assumption and may lead to unintended behavior.”

There are a variety of number systems and representations employed across a wide variety of microprocessors in the world today. These systems all depend on the correct assumptions of how binary 1′s and 0′s relate to the actual numbers the developers are expecting in their applications. With the complexity of software nowaday it is almost a given that some of these assumptions are going to be incorrect. This is why we believe many corporate applications should be thoroughly tested before being put into production.

Testing in Application Security

In-depth Application Security testing often involves detailed analysis of code-level integer arithmetic and conversion scenarios. In an application security assessment a penetration tester will use a variety of tools and techniques in an attempt to cause integer operations to occur at the bounds of the conversions. Even without code-leve application security analysis or “white box” testing a common technique called “Fuzzing” is often used by security analysts to identify these types of scenarios. In a Fuzzing scenario the security analyst will have a tool generate random data to submit to the application and then monitor its behavior for unexpected results. Thorough testing of applications by qualified security analysts can identify these types of issues before they are placed into production use.

Application Security testing can prevent not only the loss of confidential data, but also the loss of business from costly downtime scenarios such as the one experienced by the Swedish Exchange…

For more information on how WireHarbor Security can assist with testing your systems… please see our Application Security services.