Prevention, detection, and response

Today, Microsoft announced Azure DevOps – Loosely, it is TFS and VSTS, with its services broken out into distinct components that can be used together or separately. The Azure DevOps services are Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans and Azure Artifacts. When Azure DevOps was VSTS and TFS, we supported integration with PreEmptive’s Dotfuscator. Today, none of that changes. As Azure DevOps evolves, we will continue to improve our integration, so that you can easily add multi-layered protection to your valuable apps.

In Mindset shift to a DevSecOps culture, Buck Hodges, Director of Engineering for Visual Studio Team Services, stressed the importance of both preventing breaches and “assuming breaches. ”In essence, prevention only gets you part of the way there. “Assuming a breach” allows for effective incident detection, response and recovery process planning.

The .NET Conference is right around the corner. Make sure to mark your calendar because this virtual three-day developer event is not one you will want to miss. Included will be a wide variety of live sessions for beginners to advanced developers to attend.

Learn to build and the latest techniques for:

The release of Dotfuscator v4.37 yesterday marks the first big step toward a major goal: to modernize our Visual Studio integration. This release is numbered as a "minor" release - because, as always, we work hard to not make breaking changes - but its significance is actually very major.

Our current Visual Studio integration has always been one of the primary user interfaces for Dotfuscator; nearly half of our users use it, or have used it. Of those users, most are quite happy with it. (So we know that changing it is no small undertaking!)

However, there are some users who can't use it, or for whom it doesn't work very well. Notably, users with especially large projects, or complex build configurations, or more-modern projects that have heavy packaging components (including Xamarin and UWP), have all only had the option of our "standalone GUI" and a custom-made build integration.

Despite the rising costs and impact of application compromise — recent data found that 58 digital records are stolen every second and breaches cost companies an average of $3.6 million — many best practices and procedures for securely designing, developing, testing and protecting applications are largely ad-hoc. As noted by Tech Republic, in fact, exactly ZERO percent of organizations say their security needs are fully met by their current infosec strategy, down from just 11 percent last year.

Some respondents pointed to a lack of skilled resources while others cited budget constraints, but regardless of origin the outcome is clear: Hastily-designed app protection procedures that don’t meet current needs and can’t keep up with evolving demands.

Need a helping hand with your application protection process? We’ve compiled some of the best practices of leading-edge companies into a top-10 list. Let’s get started.

DashO v9.0 is out, and it has a new major version number for a very good reason: we've made some major improvements!

Java 9 and 10 support, including module support

In DashO v8.4, we introduced "provisional" Java 9 support, and we published an article describing our Java 9 roadmap. Java 9 support was provisional because there were cases where DashO would process a Java 9 app in a way that DashO thought was correct but would actually result in a broken app. As part of our commitment to the "principle of least surprise", we didn't want users to discover those issues by accident, so we made Java 9 support require an opt-in.

As of DashO 9, Java 9 (and 10) support is no longer provisional; it is a fully-supported feature, without an opt-in - and without surprises. There are a few edge cases, still, but those will generate build warnings or errors, as appropriate.

Now is the time to seriously look at how you are protecting and securing your applications

The U.S. National Institute of Standards and Technology (NIST) has published two data-security focused documents in as many months.

In June 2018, NIST published guidance on assessing requirements for securing unclassified information (NIST Special Publication 800-171A Assessing Security Requirements for Controlled Unclassified Information).

In July 2018, SPECIAL PUBLICATION 1800-1 Securing Electronic Health Records on Mobile Devices was published offering a practical guide to meeting the specialized security and privacy obligations that come with the management of health records on mobile devices.

JSON is a widely used format for sharing objects and data within an application. To protect .NET applications that serialize and deserialize JSON objects, you should be aware of some special considerations.

Consider a basic Employee class:

All apps are vulnerable. That’s the takeaway from a recent Trustwave report, which found that 100 percent of web applications could be compromised in a cyberattack. Combined with the uptick in mobile malware, account takeover fraud and blockchain-based attacks, companies spend most of their time fending off new attacks while trying to keep current apps up and running.

The result? It’s easy to assume that when applications aren’t directly under attack, they’re effectively safe. The truth? More code handling more data increases the risk of “leaky apps” — applications which unwittingly expose sensitive data to prying eyes.

Here’s how you plug the holes.