Find more about me on:
  • googleplus
  • linkedin
  • skype
  • twitter
  • youtube

Here are my most recent posts

All posts by Dan Kuykendall

Dan Kuykendall is the founder and co-CEO at the premier application security solutions provider NT OBJECTives, Inc. Throughout his career, Dan has helped develop advanced dynamic application security testing software, a fundamental aspect to NT OBJECTives’ reputation as a leader in comprehensive web application scanning. Dan has also worked for McAfee’s Foundstone and Fortis, where he founded the U.S. Information Security team. Connect with Dan on Google+
Poodle-SSL

SSL Poodle Check Added to NTOSpider

This week’s “big hack” everyone is yapping about is the POODLE flaw in Secure Socket Layer (SSL 3.0). The hack is a bad one, when the attacker can get man-in-the-middle to set it up, but the need for MitM does limit the scope of this exploit.

Adding the check for POODLE’s downgrade flag to our NTOSpider scanner was trivial as we already perform SSL Strength Analysis, but the real challenge is how to score this. Quite frankly just allowing SSL 3.0 is inherently bad, and POODLE just makes it worse. I can see an argument for making it high risk to have SSL 3.0 enabled, but then does POODLE make it “Super-High”?

As with my recent post about the 8 lessons learned from Shellshock, I encourage caution with this weekly hype cycle for each new “big hack.” It’s reminiscent of “The Boy Who Cried Wolf” – we’ll see how that will turn out for us.

HO-FFL-Logo4Post

2014 HOFFL Mid-season Update

We are about mid-season into this years Hackers Only Fantasy Football League (HOFFL) and its time to give everyone an update. Unlike last year when I did terrible and ended the season in 11th place (out of 12), I have been kicking butt and in 1st place for the last 3 weeks. Lets run through the standings

 

1st place (5-1): Your not-so-humble leaders is the one and only Dan Kuykendall (@dan_kuykendall) from NT OBJECTives. I started with a draft day ranking of #8, but have made several waiver moves that have paid off well and my hard work has me riding a 5 week winning streak.

2nd place (5-1): No surprise here, that last years winner Billy Austin (@billyaustintx) from iScanOnline is following insanely close at 2nd place with the same 5-1 record and 0.86 less points earned (I am at 691.14 and he is 690.28!).

3rd place (5-1): Alan Shimel (@ashimmy) from The CISO Group, who has been riding the Andrew Luck freight train is doing well and could easily win against any team in the league.

4th place (5-1): In 4th place we have my co-panelist at this weeks Hou.Sec.Con, Mr. Matt Johansen (@mattjay) from WhiteHat Security who has luckily scraped by some super close wins (one by 0.18 points). However, a win is a win, and hes marching trying to win the league.

We then have several 3-3 teams

5th place (3-3): NTO‘s own Dmitriy Kashitsyn (@dmk1492) who ignored my advice in week 5 and as a result secured a win against the Denim Group duo.

6th place (3-3): Kenny Herold (@glumdragonfly) has an incredibly consistent win-loss-win-loss-win-loss-win-loss record

7th place (3-3): My buddy David French (@frenchdc) from Risk I/O who drafted very well, only to have all his top picks become total flops this season.

8th place (3-3): Newcomer Kenneth Pfeil’s team cant stay consistent. Some weeks hes one of the top teams, and the next hes terrible. Ahhh the joys of fantasy football!

9th place (2-4): Proving that 2 heads are not better than 1! Lee Carsten (@lcarsten) and Patrick (@patrick_adam) from the Denim group seem to have some of the worst luck that resulted in some painful losses.

10th place (2-4): Joe Sanders (@joesanders02) better pick up the pace of wins or his hopes of sneaking into the playoffs

Finally the winless teams!.

11th place (0-6): Finally pulling out of last place is Ms. Erin (@SecBarbie) from UrbaneSec. SecBarbie has had awful misfortunes from the draft to each weeks match-up. I hope she wins this week as she faces Alan Shimel’s team.

12th place (0-6): I am not sure what to say here. My buddy Michael Farnum from HP (@m1a1vet) is doing everything wrong. Hes gotta step up his game, and when I see him tomorrow I plan to remind him of that early and often!

Well, there you have it folks! I hope your enjoying your own fantasy football leagues as much as we are!

 

Bullet-Train-Velocity

Dynamic Application Security Testing (DAST) is Anything but Static

5 Things A Modern Scanner Must Have

Dynamic Application Security Testing (DAST) solutions have been around for over a decade, so you might think the market is static. But, that’s hardly the case. Web applications and malicious hackers continue to evolve and DAST solutions need to keep pace. According to Gartner, DAST technology analyzes applications in their running state (in real or “almost” real life) during operation or testing phases. It simulates attacks against a Web application, analyzes application reactions and, thus, determines whether it is vulnerable. [Gartner Magic Quadrant for Application Security Testing, Neil MacDonald, Joseph Feiman, July 2014]

Visit this NT OBJECTives’ Gartner resource center to review some of the latest research on DAST technology.

  1. Ability to Test Web 2.0 (AJAX), Web Services, and Mobile
    Applications have evolved to be very complex and transactional – leveraging web services, mobile components and complex workflows like shopping carts. These applications are built with new technologies like HTML5 that delivers the rich clients that today’s consumers expect and REST interfaces used by AJAX. These REST interfaces also power most mobile apps, and business to business API’s. It’s critical that today’s scanners understand these new technologies.If a dynamic application security scanner hasn’t been modernized to understand these new technologies, it’s almost certainly completely skipping that area of the application leaving it untested or requiring that entire section to tested by hand. Most of the pen testers I know already have their hands full testing advanced business logic and other hard to reach areas. DAST solutions should be automatically covering as much of these applications as possible.
  2. Continuous Integration API’s to Support the SDL
    Most of the global enterprises we work with require extensibility to enable them to drive security earlier into the software development lifecycle (SDL) and to connect with existing and home grown tools. Many organizations are integrating their DAST solutions into their Continuous Integration solutions (HudsonJenkins, etc) to ensure security testing is conducting easily and automatically before the application goes into production. This requires a dynamic application security scanner that works well in “point and shoot” mode and offers open API’s for running scans. Ask your vendor how their scanner would fit into your CI environment.
  3. DEV/QA Integration and Flexible Training Options
    Security teams are collaborating with development and QA teams to leverage the test automation tools & scripts such as Selenium to create repeatable security tests that can be executed in conjunction with nightly application builds. This is an excellent way to build security into the process from the beginning with very little additional effort. Talk to your DAST scanning vendor about how their integration with Selenium and other automation tools works.
  4. Enterprise Reporting for Metrics
    Enterprise reporting means different things to different people, so one of the key features a solution should have is flexibility with open access to raw data for custom analytics. You want to make sure that your vendor does not hide the data in any way, and preferably makes it readily available with standard database query option.
  5. Point and Shoot High Quality Results
    This one is critical! Your dynamic application security scanner must do everything possible on its own to comprehensively crawl the application and then attack it. Of course training can help, but the problem is that organizations often have too many applications and the security team rarely has the time or knowledge of each application to ever possibly be able to train the scanner for them. Additionally that human time could be better spent by the security team to test things that automation cannot, such as privilege escalation and cross-account data leakage.

Ask your DAST vendor if their scanner requires training in order to understand your complex applications, and then test them for yourself.

shellshock-bug-breaking-news2

Shellshock Bash Bug – 8 Important Lessons

While Shellshock has been all over Twitter and talked about on prominent news outlets, I’m still shocked that there is comparatively less press coverage than there was for Heartbleed which was a bonafide “big story.” This is unfortunate because in some ways the Shellshock exploit is more devastating, but there are actually some good reasons for the lesser coverage, and all of them are things we should learn from.

1. Name Game Confusion
Some call it Shellshock, or the Shellshock Bug, some call it the “BASH Bug” and sadly, some in the Heartbleedpress call it the “Bug known as BASH” (see video [https://www.youtube.com/watch?v=hxsb8Hzb5FQ]). Heartbleed was a cool name, and even had a cool logo that was able to capture the imagination very quickly. Maybe we need to make sure we pick cool names and create cool logos before we alert the media of a major new vulnerability.

2. Explanation of the Threat
When dealing with Heartbleed it was easy to explain that the exploit allowed an attacker to extract unencrypted information. With Shellshock, I have seen people trying to explain the exploit in terms that are meaningless to normal people.

Reporter: “The BASH Bug gives an attacker shell access to a system”
Audience: “Oh, interesting. What’s for dinner?”

We need to use simple terms anyone can understand.

Reporter: “Shellshock gives an attacker remote control of a system”
Audience: “Oh, $#@! get my IT guy on the phone!”

We are wasting our time trying to explain what BASH is or what a shell is. Come on people!

Know your audience, and speak at their level. @Lifehacker does a good job of this! http://lifehacker.com/are-bugs-like-shellshock-and-heartbleed-really-serious-1641177186

3. The Boy Who Cried Wolf
We (the security community) made such fuss about Heartbleed and we basically told the world that the internet was on fire. The problem was that most of the internet was patched within a week or two and life went on as normal. The fire was well contained by the awareness campaign which is a good thing. But we had gone a little overboard and wasted our goodwill with the press.

4. Overstatement of the Threat
Let me start by saying, that when exploited, Shellshock is bad bad news. A Shellshock exploit is worse than a Heartbleed exploit because it’s not only allowing data to be leaked, but also allows remote control of a server and could allow an attacker to make a trusted site become evil.

I see statements out there saying that 70% or even 90% of internet connected systems are vulnerable to Shellshock and that it is much worse than Heartbleed. While there may be some truth to that, and a high percentage of internet servers are indeed “vulnerable” we need to break that down a little because a very small percentage are exploitable.

5. Vulnerable Does Not Mean Exploitable
A server might have this BASH bug which can be tested on the system with a simple test command. However, to exploit this, you need to have a service open that calls BASH. The problem is that most service ports are blocked by firewalls. In most cases, there are only a few ports open to the internet that could be vulnerable, such as DNS, DHCP, SMTP/IMAP/POP3 and HTTP/HTTPS. I have seen some exploitable examples of DNS and DHCP services that shell out to BASH scripts to handle IP assignments based on user, as well as some SMTP that shell out to SPAM filtering tools. I’m sure there are many more, but these are examples and they are limited. Jose Pagliery from CNN Money explains it quite well – the world isn’t on fire, but there is a serious problem in this video.

6. What About Web Servers?
Of course this is one of the big questions because web servers are much more widely exposed to the ShellshockBASH bug. In many cases, the only ports a server will expose to the internet are 80/443 which are the HTTP/HTTPS ports. There are situations where a web server has CGI support enabled, even though it has not been the default configuration for quite some time. But if it is, then it is possible that it might have a CGI script that executes BASH. This could happen, but it’s fairly rare these days because most CGI scripts I see are written in languages such as PERL and are not exploitable with ShellShock. So, if all the moons have aligned so far and there is a BASH CGI script in use, the admins can disable the script or patch the system to remove the vulnerability.

So lets go back to the claims that 70-90% of the internet connected servers are “vulnerable”. From that we subtract the ones that have no ports open to the internet. We then remove the ones that only expose services that are not exploitable because they don’t shell out for any reason. In the end, I think we end up with a much smaller percentage, lets say 5%-10% of the servers on the internet that are vulnerable to the Bash Bug are actually exploitable.

7. Remains A Very Serious Security Issue
Even if only 5% of the servers on the internet are exploitable that still constitutes a very serious problem. It may not get as many headlines as saying 70-90% are vulnerable, but it is more accurate and helps to maintain our credibility to the wider public.

Keep in mind, that 5% of the servers on the internet being exploitable is still a VERY LARGE number of servers, and from those exploitable systems, an attacker could then attack other servers and services not exposed directly to the internet.

8. Shellshock’s Lasting Impact
I want to state once again that I strongly feel like this BASH bug is very serious, which is why I have been disappointed by the coverage about it. I also think it will be with us for a long time, because unlike the big servers powering the internet, which will get patched, many appliance type devices will never get patched such as common home WiFi & router devices, and IP enabled devices that fall into the “Internet of Things” category.

We did a great job during Heartbleed, and I believe the publicity actually helped mitigate the threat because every IT person was made aware and systems were patched quickly. It also served as something like a shark alert at the beach and many people stayed away for a few days while “the internet got fixed.”

Shellshock has not been handled as well, and I think systems that could easily be patched won’t, because we failed in the awareness campaign. I have run into many people and friends in the IT space that had not heard about it as recently as last night!

I hope we do better next time.

NTO-CI-IntegrationWithSelenium

Fix Security Defects Earlier with NTOSpider and Selenium Integration

It’s a well-known fact that it costs less to fix security defects earlier in the software development lifecycle than later. But because most security professionals are experts in security and less familiar with applications, and QA teams are experts in applications and less familiar with security, integrating security testing earlier in the software development lifecycle can be a challenge. NTOBJECTives is changing that in a big way.

As innovators in web application security scanning, we are always thinking how can we can continue to push ourselves, to continue our innovation and really deliver world class scanning to our customers. One of the things we have done is enhance our web application security scanner, NTOSpider, to integrate with browser automation program Selenium to help companies bridge the gap between software development and security testing.

Selenium-Integration-Soultion

Here’s how it works. First, you may already be familiar with Selenium. It is often used by software development and QA teams to automate the security testing of web applications, and enable users to record a series of events and analyze the results. The NTOSpider and Selenium integration enables security teams to automatically detect security defects earlier in the software development lifecycle, such as during the nightly build process. As a result, security teams can improve web application security with minimal additional costs and without the help of development and/or QA teams.

Our latest version of NTOSpider supports two methods of Selenium integration:

  1. It executes the Selenium script directly, while NTOSpider is running, to avoid working from a possibly expired session.
  2. It imports the output of a previously executed script, expediting the testing process.

In addition to improving web application security testing, NTOSpider’s integration with Selenium can also be used to automate complex authentication solutions and specific application workflows, like shopping cart sequences.

NTOSpider offers development/QA and security teams an exciting opportunity to finally close the knowledge gap that often exists between them and develop more secure web applications at a lower cost. If you’d like to learn more about the benefits of integrating web application security scanners with Selenium or how NTOSpider can “piggy-back” on the application knowledge built into Selenium, I encourage you to download our white paper, The Case for Integrating Selenium and Application Security Testing.

This becomes even more interesting when you hook all this together with a Continuous Integration solution such as Jenkins. In this model, NTOSpider scans are launched against the latest build of the application in a fully automated fashion.NTO-CI-IntegrationWithSelenium

And while the integration of Selenium is an exciting one, we are off and running on our next enhancement. More on that soon!

Until then, scan your apps or face attack!

AppSecUSA.2014

Hackazon, new open source vulnerable web application – Sneak Peak at AppSecUSA

I hope you’ll join me next week at AppSec USA 2014 in Denver as we unveil a new open source vulnerable web application, called Hackazon in interactive group discussion, on Friday September 19th from 8:30am – 9:15am. The talk is titled, “Hackazon: Get Your App Scanners Ready.”

AppSecUSA.2014

Many IT security professionals are concerned about their ability to adequately test modern web and mobile applications as well as web services and rightly so, because today’s modern web applications have a host of new technologies that are not being adequately tested. A critical part of the ability to test today’s applications is honing your skills and evaluating the effectiveness of the security testing tools your team uses. We have some great test applications that have served the industry as a learning platform, but these applications are dated and none of them (e.g. WebGoat, DVWA, Hackme Bank and Hackme Casino) have use cases and technologies that reflect the real world applications we are seeing today.  All of the older vulnerable web applications were built on good old GET and POST (the year 2000 called, it wants its request response traffic back). 

Enter Hackazon! Hackazon is built with the rich client and mobile technologies used in today’s applications. It’s an online storefront with an AJAX interface, strict workflows and RESTful API’s used by a companion mobile app. And, it’s littered with your favorite vulnerabilities like SQL Injection, cross-site scripting and so on.

Hackazon enables users to configure each area of the application in order to change the vulnerability landscape to prevent “known vuln testing” or any other form of cheating. Since the application includes RESTful interfaces that power AJAX functionality and mobile clients (JSON, XML, GwT, and AMF), users will need to the latest dynamic application security testing tools and techniques to discover all the vulnerabilities. Hackazon also requires tedious testing of strict workflows common in todays business applications, like shopping carts.

During my workshop at AppSec USA, I’ll give a sneak preview of Hackazon, and seek your input as to what you’re seeing in applications and would like to see in Hackazon.

Looking forward to it! Hope you’ll join me for a lively discussion!

Hackers Only Fantasy Football League

Are You Ready for Some (Fantasy) Football?

Peyton-Manning

The 2nd annual Hackers Only Fantasy Football League is back! The HO-FFL is a great way for us IT security professionals to enjoy some time together outside of the workplace. This season we have some of the leading web application security companies represented, along with AppSec consultants and users of the products.

Prior to our inaugural season last year, I discovered a bug in the Yahoo! Fantasy Football mobile app, where session tokens that would never expire and allow man in the middle attacks to hijack them – to be used to their advantage against their rivals. The bug has since been fixed by Yahoo!.

This season is fired up and ready to start. The teams were drafted on Friday and now we eagerly await the start of the season tomorrow. We have an amazing collection of bright minds in the InfoSec industry that will battle head to head this season for the inaugural trophy.

fantasy-football-wizard

Along with myself, we have several returning players

  • Billy’s Team – Billy Austin from iScan Online’s returns as our defending champion. He just so happened to draft the highest scoring player from 2013, Peyton Manning. Billy happens to be my first opponent. I’m hoping that Peyton doesn’t repeat his Week 1 performance from last year when he threw for 7 touchdowns against Baltimore.
  • Hash Crackers – Lee Carsten and Patrick Adams of the Denim Group took a distant second place last year, but got the top score for their draft this year.
  • Tomball Cowboys – Michael Farnum from competitor HP and founder of my favorite local conference, HouSecCon. Farnum’s draft grade was the worst, and asks’ did “Tomball Cowboys Throw the Draft on Purpose?
  • Megatron – David French of Risk I/O who decided to chase Farnum down toward the bottom with his grade stating that “Megatron Obviously Hates Winning”.
  • Boca Steelers – Alan Shimel currently of The CISO Group and formerly of StillSecure. And before that Alan was hanging with Al Gore helping to create the Internet….and before that he was with Edison harnessing electricity.
  • brb…. Football 0x2 – The one and only SecBarbie aka Erin Jacobs of UrbaneSec.
  • Man vs FF – Finally myself, Dan Kuykendall from NT OBJECTives. The yahoo score nicely sums up my draft this season “Despite a Formidable Set of WRs, Man vs FF Has Roster Filled with Meh”.

We have a few new players this year

  • Pfeil Not Found 404 – Kenneth Pfeil of Pioneer Investments who comes in with one of the coolest team names.
  • OR mattjay=mattjay – WhiteHat Security’s very own, Matt Johansen. Only fantasy football can bring together so many competitors.
  • Lobotomy Sleuth – Kenny Herold of Cargill one of the world’s largest, privately-owned businesses.
  • Broadmoor Trash – Joe Sanders of Equifax (I hope when I beat him in week 4, that it doesn’t hurt my credit score!).
  • Orange County Bears – Dmitriy Kashitsyn the Director of Engineering at NT OBJECTives. Dmitriy made me worry during the draft when he asked “What does QB mean?”. Hopefully he busts out his ‘Football for Dummies’ book quick!

We will have a few opportunities to get together and share drinks and catch up (or smack talk) at events such as OWASP AppSec USA (9/17-9/19), HouSecCon (10/16) and RSA 2014 (2/24/2015-2/28/2015). These are great chances to see familiar faces and build upon new relationships built over the bond of Fantasy Football!

1.7 Automation Reduces Man Hours

Application Security Scanning Today – Big Organizations, Big Challenges

IT security teams in global enterprises face significant challenges in application security scanning that create the need for application scanners to deliver a scalable solution that is capable of assessing today’s applications. At NT OBJECTives, most of the organizations we talk to and work with are some of the largest organizations in the world. They are dealing with tremendous challenges from numerous applications and limited resources to ever changing technology. Let’s examine the three key challenges many of our customers face.

1. Complex Applications, New Technologies

One of the primary challenges in application security testing today is the complexity of modern applications.

“The surface of attacks targeting applications and data has expanded from Web into mobile and cloud systems. Rapid adoption of detection and protection concepts and technologies is critical for all enterprises.”
Section from Gartner other report on market state
Hype Cycle for Application Security 2013, July 25, 2013

Today’s applications are written in different technologies and those technologies are constantly changing and evolving. In the early 2000’s, most applications were simple HTML applications. Now with Rich Internet Applications (RIA’s), mobile and cloud applications, we have a host of new technologies used in applications. These technologies include everything from AJAX and Google Web Toolkit to REST and JSON.

Most application scanners have fallen behind the innovation curve and can no longer automatically or accurately assess applications that include these technologies, leaving enterprises vulnerable.

The-Wideneing-Coverage-Gap

Scanners were historically based on their ability to crawl an application in order to understand it and they were able to crawl HTML, but this is no longer the case. A new architecture and approach is required for these newer technologies. From what I can tell, NTOSpider is the only that has been modernized to address today’s applications. Be sure to examine your application security scanner carefully to determine if it’s covering the newer technologies. To read more about dynamic application security tool coverage of new technologies, please check out our white paper, “Is Your Scanner Like the Emperors New Clothes?”.

2. Enterprise Scalability & Automation

Compounding this issue of the complexity of applications is the sheer volume of them. Today’s enterprise security teams are faced with the enormous challenge of securing hundreds or thousands of applications, built in a variety of technologies with small security teams.

In order to effectively secure that many applications, security teams require a high-level of sophisticated automation. We often refer to the breadth of scanner coverage – is it covering this AJAX corner of the application, or that complex business workflow.

Considering Application Security Scanner Coverage

Application scanner coverage is the percentage of an application that a scanner can automatically understand and test. As an application scanner’s coverage of applications increases, costs for scanning all of the organizations application’s decreases. In order to achieve maximum scalability, organizations should use maximum automation. Maximum automation is derived from maximum application coverage by a scanner. There aren’t any application scanners that can scan 100% of a complex application because they will always require some testing by hand for certain business and application logic functions. However, scanners should be able to achieve maximum coverage of a complex application. Roughly 80% of a security test, even on a complex application, is capable of being automated.

For this discussion, I’m using a sample organization that has 80 standard applications and 20 complex applications.  The potential cost savings of using an application scanner with maximum coverage available (80%) would be about $228,000 or 1520 man hours per scan cycle. Many organizations do quarterly cycles, so this can result in a savings of approximately $1m per year. The following tables and graphs demonstrate the business case for maximum automation.

Cost Savings Driven by a Highly Automated Scanner for 20 Complex Applications

The table below details the time and cost savings realized with improved automation (scanner coverage) for one cycle of testing for the 20 complex applications. Using this rough estimation technique, you can see that an organization can save $80,000 in one testing cycle where 20 complex applications are tested one time.

For the purposes of this example, I am estimating the cost per pen test hour at $150 and estimating the man hours required to complete a scan based on the coverage the application scanner can provide and the complexity of the application. The estimated total man hours required for testing the applications is multiplied by the $150 to get the cost for the apps for each row.

The following table demonstrates how total security testing costs decrease for 20 complex applications as the application security scanner’s % coverage of the application increases.

1.0 Time & Cost Savings for Complex Applications

Note: The column called, “Man hours required to complete a scan” refers to the total number of human hours required to assess an application including: configuration time, pen testing time, vulnerability review and validation time, etc.

So, if we look at the same cost savings for 20 complex applications in a graph, we can see that as scanner automation improves, costs decrease. 

1.1 1.1 Cost Savings with Improved Automation (20 Complex Apps)

Cost Savings Driven by a Highly Automated Scanner for 80 Standard Applications

So, does the same logic hold true for more standard applications that are less complex? This table details the time and cost savings realized with improved automation for 80 standard applications over one test cycle. Again, using this rough estimation technique an organization can save $72,000 in one testing cycle where 80 standard applications are tested one time.

1.2 1.2 Time & Cost Savings for Standard Applications

Again, looking at it in a graph format, you can see that as scanner automation improves, costs for testing 80 standard applications decreases. With 50% coverage, the applications will cost around $120,000 to test, but with 90% coverage, the costs decrease to less than $20,000.

1.3 1.3 Cost Savings with Improved Automation (80 Standard Apps)

Cost Savings Driven by a Highly Automated Scanner for 100 Mixed Complexity Applications

So, when you look at all 100 applications of mixed complexity, again we see that as scanner coverage increases, man hours and therefore overall costs, also decrease.

1.4 Time and Cost Savings (100 apps, mixed complexity)

And the graph demonstrates that  an organization can save almost $200,000 by testing all 100 of their applications one time with maximum automation as opposed to 50%.

1.7 Automation Reduces Man Hours

3. Scalability with Cost Control

A third major issue is that most of these organizations are building world class application security programs to address thousands of web and mobile applications with limited financial and human resources in a race against ever increasing threats. This challenge requires them to find highly automated and distributed application scanning solutions while effectively using resources to control costs.

But controlling costs is difficult. The smartest solution is one that combines the most accurate and automated web application vulnerability scanning with the benefits of elastic computing in the cloud to provide a sophisticated and scalable solution that effectively controls costs while conducting automatic vulnerability detection for even the most complex applications. Our scalable, elastic solution leverages NTOEnterprise and enables the largest global enterprises to provide their own application security assessment shared services to their customers or different divisions around the world.

A highly sophisticated and automated solution combined with elastic computing enables global organizations to easily expand and contract resources based on their scanning demand.

At NT OBJECTives, we have always strived to maximize automation. We find that many of the largest organizations in the world choose us because the complexity of their application security program necessitates sophisticated automation, maximum application coverage and scalability. For more information about how we solve these problems, please visit us at www.ntobjectives.com or request that we contact you by filling out this short form.

iphone image

Mobile Application Security 101

Mobile Applications – Still Insecure

Businesses are racing to meet the demands for mobile applications, yet mobile application security is an afterthought, just as web application security was when web applications started to proliferate.

As an industry, we know so much about securing web applications that applies to mobile, but most organizations are still repeating past mistakes and making new mobile specific mistakes that expose businesses to security incidents.

According to a recent Gartner report, “Most enterprises are inexperienced in mobile application security.  Security testing, if conducted at all, is often done casually — not rigorously — by developers who are mostly concerned with the functionality of applications, not their security.[1]” In this same report, the firm indicates that “through 2015, more than 75% of mobile applications will fail basic security tests.[2]

Friends-using-Foursquare-006

Don’t Forget Mobile Web Services

There has been so much talk about mobile device and mobile client security, but the key thing to keep in mind when approaching mobile application security is that it’s critical to test both the client as well as the communication to the web service that powers it. For example, if you’re using your Twitter app, the primary logic that resides on the mobile client is display and user authentication. The app must then communicate to a web service in order to get and send Tweets. This web service is the real power of Twitter and where the real security risk lies. Why attack one user, when you can attack that web service that is used by millions?

Even though mobile applications leverage a client-server model, they are built with entirely new technologies that necessitate new processes, technologies and skills.  While mobile application security does drive these new requirements, the overall problem is one that the security industry is already well acquainted with because the vulnerabilities showing up in mobile applications aren’t new at all. We often say that we are “Hacking like it’s 1999” because, the reality is that mobile vulnerabilities are are just the same old vulnerabilities that we have been hunting for over 13 years now: SQL injection, overflow, and client attacks.

These new requirements for mobile testing are driven by the new programming languages used for building mobile clients (Objective-C and Android’s Java variant), the new formats used by back-end web services (JSON and REST) and the new authentication and session management options (OAuth, HMAC, etc). And while those familiar SQL Injection attacks look almost exactly like they did 10 ago, you just can’t find them without understanding how to deliver these attacks within the new structures.

iphone image

SQL Injection Alive and Well

We call the mobile vulns the Where’s Waldo of application security. They’re your old familiar friend, SQL Injection, who looks almost exactly like he did 10 years before – maybe with a few gray hairs – but you just can’t find him as easily because he’s in an all new environment. We simply need to adjust to this new landscape and start looking for our old friend again.

Another important thing to keep in mind about mobile application security testing is that there ARE tools that automate the process. There just aren’t that many of them that automate the entire process or do it very well.

We see several categories of security vulnerabilities in mobile applications:

More on Mobile Application Security

 

[1] [2]Gartner Research Document

Gartner, Technology Overview: Mobile Application Security Testing for BYOD Strategies, By Joseph Feiman and Dionisio Zumerle, August 30, 2013.

Mobile-App-Sec

Mobile application security testing – fast and easy!

Mobile-App-SecMobile application security testing: Four words that, for many security professionals, elicit a nagging feeling that comes from knowing the challenge is imminent if not already present, yet very difficult to tackle.

We at NT OBJECTives understand, and we’ve got your back. Our newest service offering is designed to help busy security teams easily and thoroughly test mobile applications – without intensive training or resource drain.

NTOMobile On-Demand gives NTOSpider customers everything they need to quickly security test mobile applications, including mobile client native code and back-end web services. No need to choose between testing the source code, testing the services or pen testing the mobile app. NTOMobile On-Demand does it all with a comprehensive software solution combined with expert pen testing.

Comprehensive mobile application testing requires both static and dynamic analysis, so we’ve packaged them together, along with expert pen testing, to deliver comprehensive mobile application security testing. By leveraging the power of NTOSpider’s dynamic application security testing capabilities, NTOMobile On-Demand effectively and automatically tests the web services that power mobile back ends and that leverage new technologies like REST, JSON and SOAP. You won’t find another web application security testing solution that delivers better coverage of your custom web service implementations.

Mobile application security testing is a challenge for security teams that don’t have the time or resources to invest in effective training and tools. NTOMobile On-Demand enables security teams to conduct comprehensive mobile application security testing – and obtain the peace of mind that comes from doing what needs to be done.