Tuesday, August 30, 2016

Your iPhone is at Risk – Apple Releases Critical Update

shutterstock_275558726Apple released a critical update on Thursday, August 26th, to address a series of flaws in the iPhone 6. The flaws, while individually of little concern, combined to allow hackers to remotely jailbreak the iPhone.

The vulnerability was discovered and reported to Apple about a week and a half ago, after a United Arab Emirates human rights activist was targeted by the attack. Ahmed Mansoor reported the issue to researchers at the University of Toronto’s Citizen Lab, who in turn found and reported the issues to Apple.

Mansoor received a text message containing a link. Following the link would have installed a program that would have allowed remote access to his phone, thanks to three previously unknown flaws in the iOS operating system. Once installed, the hackers would have had access to a number of iPhone services, including being able to control the camera and listen in on conversations using the microphone.

The spying goes beyond those services, however. Once the exploit is installed, hackers have access to the location of the phone and can listen in and record conversations. Even apps using end-to-end encryption, like Whatsapp and Viber, would be subject to access. Additional assets at risk include stored photos, files, and messages in mobile chat apps.

As the number of features available on smartphones increase, so do the number of potential risks. Each of the flaws in iOS flew under the radar – Citizen Lab stated they believed these flaws to have been part of the OS since 9.3.3 or before. (iOS 9.3.3 was released on July 18th, 2016.)

It was the combination of several flaws that enabled the creation of the larger – and far more dangerous – exploit.

At this time the reported cases are limited to Mansoor, a Mexican journalist and a minority party politician from Kenya. But now that the flaws are known, it is only a matter of time before the larger community attempts to use the security hole on a larger scale.

This is why it is critical that iPhone users ensure they update to the new patch, version 9.3.5. With the smartphone becoming the holder of our credit card information and other personal data, anything providing unfettered access to your phone is a major concern and an opening for identity theft, credit card fraud, and even, with this current issue, corporate espionage.

In 2015, there were over 94 million iPhones in the hands of users. Many of these are in use, on a daily basis, by executives and leaders in enterprises across the country, and the globe. With an unpatched iPhone company files and messages could be harvested from your phone. Even meetings could be eavesdropped on with a compromised phone using the device’s mic.

And this goes beyond executives, to all levels of the organization. It is critical for your IT security teams to encourage all iPhone users, whether issued by the company or not, to update their phones.

Consider having your security teams send an organization-wide message alerting users to the threat and including simple instructions on how to apply the update to their phone. Also, remind your users about good security practices. Reinforcing messages should be an important part of your enterprise security training, especially when the opportunity to do it in the context of a real world example presents itself.

One last note. As of the time of this writing, the vulnerability has not been found in iOS 10 beta. So an alternative is to upgrade to the new OS. But because it is still in beta, the usual caveats and cautions for early adopters apply.


The post Your iPhone is at Risk – Apple Releases Critical Update originally appeared on the Curotec Blog

Monday, August 22, 2016

The Basics of Domain Driven Design

domain-driven-designStop me if you’ve heard this one before.

A developer walks into a requirements review and after a few minutes says “But this is just like part of the application we wrote 6 months ago.”

The lead says “Can we reuse that code?”

The dev says “It would take longer for us to abstract it than to just rewrite it. It’s in there with other functionality specific to that app.”

And no one laughs. We’ve all been in this meeting, felt the frustration bubble up. The business doesn’t understand why it will take so long to build. The IT leadership is shaking their heads because we’re not able to leverage what’s already been built. And the developer is grinding their teeth at having to solve the same problem, again.

For those of us with experience and background in software development, we know this isn’t how it’s supposed to work. What happened to breaking problems down, building re-usable objects, abstracting functional layers?

There are lots of reasons good development practices fall to the wayside. Lack of understanding of the business problem, crunched timeline, and budgets are all excuses for setting aside properly engineering a solution.

Domain-driven Design would like to change that. It’s not a methodology, like Agile, or a process like RUP (Rational Unified Process). Instead it “provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.”

Like all tools, DDD has a time and a place. But when used in the right context, at the right time, and applied correctly it can bridge the gap between the business and developers and lead to efficiency in enterprise development.

What is Domain-Driven Design?

DDD was introduced by Eric Evans in 2003 in his book of the same name. In it, Evans outlines a systematic approach to understanding complex business problems and applying domain models to those problems to create organized and focused solutions.

The intent, of course, is to build better, more re-usable, more cost effective software, especially in the face of highly complex business systems. Evan’s approach enables developers to better understand the business problem and communicate more effectively with their business counterparts.

It is also intended to help developers to better size down problems and fence in what they are building. As the old saying goes, you eat an elephant one bite at a time. But thanks to the evolution of software solutions and network computing, those bites speak to modern software architecture.

As enterprises continue to adopt and adapt to software services, having an approach that maps out how to break a business need down into service, and even microservice components that become useful and re-usable. But starting with services encourages a bottom-up design.

DDD, on the other hand, starts at the top. It directs teams to create a common language with the business before solving the business problem. To understand how it does this, let’s look at the basics of DDD.

 

DDD 101

Clearly, the first thing to understand with Domain-Driven Design is to define what we mean by a domain.

The domain is, basically, the business area we’re talking about. It’s the area of the business relevant to the solution needed, and to help you define and find your domain experts.

Are you talking about a new CRM? You’ll want someone from sales. New call center software? You’ll want a call center manager. A new CAD system? Bring in an engineer.

What you want is someone with a business understanding of the problem you’re trying to solve with a software implementation. That’s your domain expert.

But a common problem with humans in general, and in business to IT communications, is making sure you are all speaking the same language. That’s where the next step of DDD comes in – creating what Evans calls a Ubiquitous Language.

This will be the cornerstone of communication for everyone who works on the project. It will define the language the team will use to talk about the project. And it will evolve and grow over time, through trial and error.

For instance, if you were asked to build a car, you might think “sports car” while the product manager means “family sedan”. So you define that, for the purposes of this project and this domain, “car” means “family sedan”.

It’s a bit of a contrived example, but you can see where not having that definition in place would lead to some costly trouble.

Once everyone is speaking the same language, developers can break down the domain into smaller sub-domains and bounded contexts. A bounded context is like a miniature application, and has its own domain.

Think of an eCommerce system. By itself, it is a context – one where people use the application to shop. But, within that context lie smaller domains, like customer information, payment processing and inventory. Each of these is a bounded context, with one domain.

There is more detail within Domain-Driven Design, much of which is outside of the scope of this article and begins to dive into more technical nitty-gritty.

But the above describes how DDD begins to handle the parts of a project with the greatest potential for complexity – what the business needs are and how to build an understanding across the team.

Breaking the project down, bit by bit, allows the teams to develop highly modular pieces of code. Code that can be re-used. Code that can be refactored without upending an entire system.

 

Benefits to the Enterprise

The greatest gains to the business for DDD come from highly complex applications and domains.

First, the organization as a whole has a greater understanding of the domain, thanks to the need to model it for the ubiquitous language and bounded context.

The enterprise also creates a common language that can be used within the context of building out the solution, but can also be carried throughout the domain and the organization.

Better code can be created because the domain experts are an integral part of understanding the problem, and the solution.

The solution is better organized and focused thanks to the defined contexts.

The enterprise gains re-usable services that can be iteratively improved and changed without taking down entire business systems.

 

Not a Silver Bullet

But DDD is not a silver bullet that will solve every issue in your enterprise.

First, it can be overkill on smaller and less complex projects, or projects with a limited life span or usefulness to the organization.

And while building a domain model can be helpful in and of itself, it isn’t DDD, but only a part of it.
Domain models are time consuming to build and require resources from IT and the business. Likely from multiple business units.

There is much effort at the start required to define the domain, subdomain, contexts and ubiquitous language. And that means greater cost to the organization, up front. With the possibility of the return on that investment being months or years down the road.

Domain-Driven Design is an effective set of techniques for complex, enterprise level software projects that will have years of life within the organization. And principles of DDD, individually, have merit for the organization that is willing to commit resources early on. But just like holding a daily stand up meeting is not the same as implementing Agile, creating a domain map isn’t the same as following DDD.

And yet, for those projects that fit the mold, DDD is worth deeper investigation as a means of bringing greater understanding and more modular development.


The post The Basics of Domain Driven Design originally appeared on the Curotec Blog

Thursday, August 4, 2016

HTTPS Exploit Can Steal Your Secure Data – Black Hat 2016

IT security is top of mind for many enterprises these days. And with the announcements coming out of the Black Hat Conference that won’t be changing anytime soon.

On Wednesday, August 3rd at the Black Hat 2016 conference in Las Vegas there was an eye opening demonstration on the need for updated Internet security protocols. At a briefing entitled “HEIST: HTTP Encrypted Information Can be Stolen Through TCP-Windows”, researchers Mathy Vanhoef and Tom Van Goethem demonstrated a set of techniques that would allow hackers to listen in on secured traffic directly, without the need for an intervening network.

Used to transfer information over
HTTPS Exploitthe Internet, HTTP is the foundational protocol that enables communication over the Web. HTTPS uses this protocol combined with Transport Layer Security (TLS), or its predecessor, Secure Sockets Layer (SSL), to provide secure communication over the Internet. Using HTTPS authenticates the connection between a user’s browser and a web server to protect private information that is passed between the two.

One of the purposes of using HTTPS is to prevent a man-in-the-middle atttack – an attack in which a hacker impersonates each of the end points in the communication. The user’s web browser thinks it is speaking directly to the web server, and visa versa, while the messages are actually being passed through a third party. Because of the end to end authentication with HTTPS it is difficult to impersonate or even eavesdrop on the data being passed back and forth.

With the newly discovered HEIST technique, a man-in-the-middle attack is no longer needed. In fact, as described in detail in this article on Ars Technica, the user only needs to “encounter an innocuous-looking JavaScript file hidden in an Web advertisement or hosted directly on a webpage”. This code can then be used to find out information about the file sizes transmitted from TLS or SSL secured pages and use that information, combined with another attack, to tease your information out of the HTTPS encrypted responses. These could even be small pieces of data with a big impact – like your email address or social security number.

Once HEIST has the files size, it partners with other exploits to use HTTPS’s security measures against itself. You see, most websites use compression in their responses by not repeating text strings within the data. Exploits like BREACH, being discussed on Thursday at the Black Hat conference, use this information to play an intelligent game of true or false. The exploit guesses part of the string, and if it’s right, the response doesn’t grow in size. Instead, the repeated strings are removed by the compression. If it’s wrong, the compression can’t eliminate the string, and the response grows. And now, thanks to HEIST, the exploit knows the file size of the data.

The good news is that a number of tools are being released this week to help teams assess their vulnerability to BREACH. The bad news is that the only way known, at the moment, to mitigate HEIST is to turn off 3rd party cookies. These are on by default in most browsers and will cause a number of online services not to work.

Expect to see recommended changes to your applications to reduce the potential risk associated with these issues and even changes to best practices on how sensitive data is exchanged in Web response messages. With no blanket fixes, these exploits will take time and resources to mitigate and new policies outlining how you’ll handle data going forward. But ignoring the changes could be devastating for businesses and their customers.


The post HTTPS Exploit Can Steal Your Secure Data – Black Hat 2016 originally appeared on the Curotec Blog

Wednesday, August 3, 2016

The New Definition of Success: RJMetrics Sells to Magento, Spins off Stitch

big-data-analyticsBuilding a successful business and then selling it to a big fish in the industry is The Brass Ring for many startups. Yesterday’s announcement from RJMetrics shows they have a firm grasp on that ring with the sale of the company to eCommerce platform giant Magento. But it’s less of a buyout and more of an evolution for the Philly-based company. In fact, the deal is part of a growing trend with tech companies and startups, enabling them to downsize with a purpose – to focus on new initiatives.

RJMetrics, Magento and Stitch

Founded in 2008, RJMetrics couldn’t have launched at a better time. Coming just as words like “data insights” and “big data” were passing the lips of every CIO, RJMetrics grew into a multi-product offering. Their suite gives businesses the intelligence they need to acquire customers, get them to buy and get them to stay.

With those kinds insights, it’s no wonder that RJMetrics caught the attention of California-based Magento. The acquisition, for an undisclosed sum, was announced yesterday and brings a solid competitive advantage to both Magento and their customers. Marketed as Magento Analytics, the solution will put the power of business intelligence and data insights into the hands of B2B and B2C merchants using the Magento platform. This will bring enterprise level analytics and actionable data to non-technical users of the platform.

The deal also acquires half of the current RJMetrics staff and allows Magento to set up a presence in Philadelphia. But what about the other half? This is where the story goes beyond a mere acquisition.

The other half of the RJMetrics staff, including RJMetrics co-founders Jake Stein and Robert J. Moore, have spun off into a new company, Stitch. As Stein points out in his blog post announcing the new company, data has “created a headache for developers”, and Stitch is looking to be the cure.

Taking the Pain Out of Data

An enterprise’s data can live in a myriad of places in today’s connected world. You’ve got CRM data in Salesforce, email databases in Marketo, web and mobile analytics in Google Analytics, and marketing data in Facebook and AdWords, among others. There are multiple teams wanting to look at this data from every angle, and you’ve got a data warehouse ready for it.

The estimate to get all of that data into your warehouse is staggering. The estimate to maintain it is worse.

It’s an all too common complaint from developers on up – connecting data sources and getting that data to look the same for your apps and warehouse is tedious, grinding, and time consuming work. It’s not the kind of work that makes developers happy. And it takes them away from the critical user-centric application work that companies need to focus on.

But data is king, and without it many business critical applications are meaningless.

This is the problem that Stitch was created to solve by offering a managed ETL solution.

When it was initially launched as RJMetrics Pipeline application, the team did a little digging into how much time creating a proper ETL system takes. What they found was staggering, but unsurprising. Building out a solid system for data transformation and loading takes “between 8,000 and 15,000 development hours to get off the ground and then 1–2 developers to maintain on an ongoing basis”.

RJMetrics effectively removed this pain point for hundreds of developers in beta, and now, as part of Stitch, they have the chance to help even more.

Downsizing to Focus – A Growing Trend

The one-two punch of acquisition and spin-off lets the established portions of RJMetrics live on while providing the team with the chance to go heads down on their ETL solution. The new Chairman of the Board and co-founder of Stitch, Moore described the situation as creating “a future that’s exciting without disrupting the universe you’re in”. And with this move, Stitch follows in the footsteps of other tech companies who have re-focused their efforts on fewer products.

Notable in this group is the 37Signals shift that occurred in early 2014. At that time the creators of Ruby on Rails announced the decision to re-focus the company on their core product offering, Basecamp.

The company not only dropped the 37Signals branding, but also decided to divest themselves of their other products including Highrise, Campfire and more. The reason? In an Inc. article at the time, 37Signals co-founder Jason Fried said the change would “allow us to do more things with fewer people”.

Dropping everything but Basecamp allowed the company to focus on doing more with a single product – better features, more access and a more mature platform. Instead of growing their team, they kept it the same size, allowing them to maintain the family-style culture while doubling-down on a product known both inside and outside the tech industry.

Doing Good and Doing Well

The change at 37Signals was accomplished while still holding everything together, customers and employees alike. And despite a strategic layoff earlier in the year, RJMetrics was able to achieve a similar outcome.

In fact, the acquisition/spin-off of RJMetrics isn’t a case of line-your-pockets-and-run. Instead it brings a number of benefits with it

  • It brings fresh funding to the Philly startup scene
  • It has the potential to create new jobs by establishing a new Magento office
  • It has the potential to create new jobs as Stitch grows
  • It creates a dedicated, proven team to work on a new product
  • It leaves a dedicated, proven team to support existing clients

This isn’t just another acquisition of a startup. It’s part of a new breed of re-structuring that fosters better products with solid, proven teams.


The post The New Definition of Success: RJMetrics Sells to Magento, Spins off Stitch originally appeared on the Curotec Blog

Curotec Favorite Links