Red Hat Developer website editorial support

For the past several months, I have been working with the editorial team that manages the Red Hat Developers website. My role is to work with the product managers, the open source experts and the editors to rewrite product descriptions and place the dozens of Red Hat products into a more modern and developer-friendly and appropriate context. It has been fun to collaborate with a very smart and dedicated group. This work has been unbylined, but you can get an example of what I have done with this page on ODO and another page on Code Ready Containers.

Here is an example of a bylined article I wrote about container security for their blog.

How to protect your mobile apps using Zimperium’s zIAP SDK (screencast)

If you are looking for a way to protect your Android and iOS apps from malware and other mobile threats, you should look at Zimperium ‘s In-App Protection (zIAP) SDK . It supports both Apple X-Code for iOS apps and Android Studio for those apps. One of the advantages of zIAP is that you don’t have to redeploy your code because changes are updated dynamically at runtime and automatically pushed to your devices. zIAP ensures that mobile applications remain safe from cyber attacks by providing immediate device risk assessments and threat alerts. Organizations can minimize exposure of their sensitive data, and prevent their customers and partners’ data from being jeopardized by malicious and fraudulent activity. I tested the product in April 2019.

Pricing starts for 10K Monthly Active Devices at $12,000 per year, with steep quantity discounts available.

https://go.zimperium.com/david-strom-ziap

Keywords: strom, screencast review, webinformant, zimperium, mobile security, app security, Android security, iOS security

CSOonline: Top application security tools for 2019

The 2018 Verizon Data Breach Investigations Report says most hacks still happen through breaches of web applications. For this reason, testing and securing applications (from my CSOonline article last month) has become a priority for many organizations. That job is made easier by a growing selection of application security tools. I put together a list of 13 of the best ones available, with descriptions of the situations where they can be most effective. I highlight both commercial and free products. The commercial products very rarely provide list prices and are often bundled with other tools from the vendor with volume or longer-term licensing discounts. Some of the free tools, such as Burp Suite, also have fee-based versions that offer more features. You can review my list in CSOonline here. 

 

 

CSOonline: What is application security and how to secure your software

Application security is the process of making apps more secure by finding, fixing, and enhancing the security of apps. Much of this happens during the development phase, but it includes tools and methods to protect apps once they are deployed. This is becoming more important as hackers increasingly target applications with their attacks.

In the first of a two-part series for CSOonline, I discuss some of the reasons why you need to secure your apps and the wide variety of specialized tools for securing mobile apps, for network-based apps, and for firewalls designed especially for web applications. Next month, I will recommend some of these products.

Blogger in residence for SaltStack conference

I wrote a series of blog posts at the SaltConf18 in September 2018. SaltStack is a devops automation, remote control and orchestration tool that has a great deal of power and is used in some very large enterprise networks managing hundreds of thousands of servers.I also wrote white papers about their technology and its applications.

Here are links to the various pieces:

blog post of news announcements from day 1 of the conference

— I wrote this white paper which talks about typical use cases of the SaltStack Enterprise product and Salt’s key features.

Understanding security automation in the context of the stages of grief

The relationship of the digital and physical worlds has never been closer, a post about Cyndi Tetro’s session.

— Examinging how IBM Cloud and Cloudflare use Salt to manage their global networks (forthcoming)

SaltStack: beyond application configuration management

When it comes to building online applications, you can build them with old tools and attitudes or with new methods that are purpose-built for solving today’s problems and infrastructures. Back in the days when mainframes still walked the earth, setting up a series of online applications used some very primitive tools. And while we have more integrated development environments that embrace SaaS apps running in the cloud, it is more of a half-hearted acceptance. Few tools really have what it takes for handling and automating online apps.

Today’s IT environments are in a constant state of flux and moving at an unprecedented velocity. The tools used to manage these environments weren’t designed for this level of complexity nor designed for rapid changes in resources. The modern data center requires juggling numerous open source repositories, handling multiple cloud providers, being able to rapidly scale up and down its resources, orchestrating changes and populating builds across multiple servers and services.

And matters are only going to become more complex. More non-digital businesses are moving into the cloud, creating new applications that make use of mobile devices that tie them closer to their customers, suppliers and partners. Digital-first vendors are adding features and integrating their websites with a variety of third parties that both increase their security risks and complicate their applications flow and logic. The old days of manual labor for handling these situations are looking more than ever like the days when we last made buggy whips.

Typical use cases

Salt was initially created to handle remote execution across complex application development environments, allowing its users to execute commands across thousands of servers concurrently and automatically. But today we need more from our toolsets than just the ability to run code remotely. Since it began in 2012, Salt has expanded its role to thrive on a mixed open and closed source environment that spans cloud and on-premises infrastructures. Here are some typical scenarios for its use:

  • A developer needs to schedule tasks that run in a particular sequence, waiting for a dependent server to reach a particular state before it can be launched. While this can be done manually, it can be tedious and error-prone and begs for more automated methods.
  • Or an IT manager needs to install a particular set of updates and patches to their environment. However, these must be done in a certain order and only when one is successfully installed can the next step be initiated. To add to this complexity, the IT department manages a mixed collection of Windows, Macs and Linux machines that carry particular pieces of their applications infrastructure. Again, this could be done manually, but not in a reasonable time when these patches have to be applied to a thousand different servers.
  • An application development manager needs to deliver the latest build of their software stack to their production environment, while ensuring that the code is secure and solid. Manual methods are inadequate to handle the velocity of coding changes and applications provisioning in any timely fashion.
  • An infrastructure engineer needs to set up a multi-tiered web and database application that will require a combination of servers, networks, storage and security devices. The complete collection spans multiple VMs, Docker containers and physical servers, all of which have separate and complex configurations where one misstep could mean a large amount of downtime and debugging.
  • A new security exploit is discovered that has massive implications across a variety of OS’s and system configurations. Security researchers recommend wholesale updates to be done as quickly as possible, to avoid any potential intrusions by hackers. Using “sneaker-net” or running from server stack to stack will take weeks to accomplish, not counting the time needed to verify the changes are made correctly.
  • An engineer wants to automatically enable auto-scaling features of their cloud provider to match the resources needed as demand rises and falls. While the major cloud vendors offer the ability to spin up and down VMs as needed, more coordination is needed to install the right series of application servers on the new VMs and to balance the overall loads appropriately. This is nearly impossible to accomplish manually.
  • Or an enterprise wants to migrate its entire cloud infrastructure from AWS to Azure, which involves moving hundreds of virtual servers in a particular order and under certain specifications for each VM. Doing this manually would involve weeks of work, and workers need automation to help with the migration.

Salt’s key features

In each of these cases, the old-school manual methods are inadequate for reasons of time, accuracy, security, or just the sheer effort involving coordinating expensive and highly-skilled IT staffers. That is where Salt comes into play. Here are some of its key features.

Salt’s event-driven automation tools make these tasks much easier to programmatically happen, without a lot of manual operator intervention

Salt also understands orchestration and how the sequencing of various steps has to occur.  Salt can handle the necessary conditional logic that control the various configuration and installation steps.

It also contains cloud controls that can manage public, private, and hybrid clouds. It can extract the infrastructure layer, spin up VMs under certain conditions and with certain configurations. This makes moving from one cloud provider to another easier and less error-prone.

Salt comes with sensors that react under certain conditions, such as the presence or absence of a particular application or detection of a particular OS version level.

As we said earlier, Salt originally was created for remote execution tasks. It deploys both push and pull architectures. This differs from many other configuration management tools which make use of one or the other methods. Salt has the flexibility to mix both kinds, making scheduling and message-connected events simple. It addition, it can handle both agent and agentless options, to give its automation processes the maximum level of flexibility and support to the widest collection of endpoint devices, servers and services.

Finally, to support all these automated methods, Salt has solid configuration management features that can detect and manage a wide variety of circumstances. All of its scripts are written in Python, making them more accessible to a wider collection of developers who have learned this language. Other tools have their own proprietary scripting tools that have steeper learning curves.

Salt is used by a wide variety of digital businesses to manage tens of thousands of VMs and physical servers, including LinkedIn and eBay. At the former, it is used to serve up massive amounts of data at very low latencies to improve usability. Salt enables ”us to quickly and dynamically provision caching layers for many of the services that make up our site,” according to that blog post. You should take a closer look at what they offer and how it can be deployed in your organization.

CSOonline: 4 open source red-team ATT&CK-based tools reviewed

In an article that I wrote last week for CSOonline, I described the use of a red team framework from Mitre called ATT&CK. in my post this week, I compare four free open source tools that leverage this framework and how they can be deployed to help expose your network vulnerabilities. The four tools are:

  • Endgame’s Red Team Automation (RTA),
  • Mitre’s own Caldera,
  • Red Canary’s Atomic Red, and
  • Uber’s Metta

Each have their good and bad points. You can read my review here.

HPE blog: The changing perception of open source in enterprise IT

Once upon a time, when someone in IT wanted to make use of open source software, it was usually an off-the-books project that didn’t require much in the way of management buy-in. Costs were minimal, projects often were smaller with a couple of people in a single department, and it was easy to grasp what a particular open source project provided. Back then, IT primarily used open source to save money and “do more with less,” letting the department forgo the cost of commercial software.

Times have certainly changed. Yes, software costs are still a factor, and while it is generally true that open source can save money, it isn’t the only reason nowadays to adopt it. While application deployment costs have risen, the direct software cost is a small part of the overall development budget, often dwarfed by infrastructure, scalability, and reliability measures.

As a result, today’s open source efforts aren’t anything like those in earlier days.

You can read the full story on HPE’s blog here.

What happened to the Web user interface?

More than 20 years ago, the Web was just getting started. People were experimenting with all kinds of web servers as publishing mechanisms and as user interfaces for various devices. Back then, I thought this was a neat idea: having a web interface was a great way to demonstrate a product across the Internet, unify the user experience across different browsers and end user platforms without having to develop separate programs for them, and perhaps simplify end user training too. It was the brave new world.

Back then, there were some dissenting voices. Having more Web UIs would ”set computer programming back 30 years and is about the worst technology I’ve laid eyes on,” said one UI consultant that I interviewed at the time. Another pointed out that the Windows graphical interface (which was just getting going back then) was far superior to anything the Web could produce in terms of interactive controls. That distinction has largely disappeared over the decades. And having the cloud to handle various tasks (think calendar synch or database queries) makes the Web UI superior to a local Windows app under certain circumstances.

I wrote about these issues for Computerworld in the summer of 1996. Back then, Netscape (remember them?) and Microsoft were duking it out over which company’s HTML extensions were going to become more popular (we know how that fight went down). At the time, I said, “having all software go to the Web UI might hasten to have an all-Windows world: since multi-platform apps can be supported by web servers, developers have moved away from Everything Else and concentrated on Everything Windows.” I don’t think that has come true, and let’s not forget about smartphone apps that have their own wicked interface with their own screen real estate limitations.

I asked my favorite UX consultant, Danielle Cooley, what she thought about my comments from 1996. “Things have changed dramatically, of course, both on the technology side and the design side,” she told me in a recent email. “Speaking as the user advocate, I would say consumers’ standards are much higher across the board then they were 21 years ago. Thanks to the user-centered approach taken by large organizations like Amazon, Apple, and Google, laypeople have less patience for digital products that force them to contort their thinking and behavior. Now, they have more and more access to tools that fit the way they already think and behave. Many organizations still suffer from serious UX immaturity. Lack of investment and integration here has resulted in the confusing and frustrating interfaces we’ve all come to hate. The fact that there are still SO MANY of these, 21 years after your Computerworld article, is telling and alarming.”

But the Web UI is here to stay, one way or another. Now at least we have responsive design, so at least smaller or larger screens can view appropriate webpages automatically. And hopefully, developers will finally learn what makes for a better UI experience.

Is Windows Continuum Worth Your Time?

When I was attending the Citrix Synergy show last week, much was made about the support of the Windows Continuum effort by Microsoft. This puts the Windows 10 functionality on a lot of different and non-traditional IT devices, such as the Surface Hub gigantic TV, Xbox consoles, and Windows Phones. If you look at the linked webpage above, you will see a lot of information about how you can use a Windows Phone as the basis for a new kind of docked workstation that has a real keyboard and screen attached.

When I spoke to Citrix SVP PJ Hough about this, he changed my thinking about Continuum. It isn’t all about the Windows Phone, but about the other stuff that is enabled here. Continuum is really about how you can essentially upgrade these devices to become smarter about their deployment and delivery of Windows apps themselves.

Naturally, Citrix has a vested interest here, because Receiver now supports Windows 10 S installations, which are devices that are part of the Continuum ecosystem. One of the issues for Win10 S is that it is a locked-down OS that only runs the applications delivered from Windows Store. This means if you have legacy Win32 apps on your older desktops, you were out of luck to run them before now. Having Receiver on 10 S gives you the best of both worlds: a more secure desktop that can still run your crusty older apps in a protected workspace.

Citrix Receiver — compatible with Windows 10 S — is built using the Microsoft Universal Windows Platform technology. This was introduced by Microsoft earlier this year and at this link you can find more information on how to build apps and learn from the samples that they have provided. Essentially, what Microsoft is trying to do is create a common core that app developers can use on a variety of other devices, including HoloLens and its Surface line of tablets and TVs.

But the real secret sauce of the universal platform is how it can be distributed using the Windows Store. Microsoft has learned from the Apple Store that app distribution is the real friction for getting apps to actually be used. Universal apps thus come with a built-in marketing bonus.

To make true use of Citrix Receiver, you of course will need XenApp and XenDesktop, running on XenServer or in a cloud-based infrastructure through Citrix Cloud to deliver the complete desktop experience. You can see the video of how this works here: