Category Archives: App Dev tools

CSOonline: Top application security tools for 2019

Posted on by
Reply

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

Posted on by
Reply

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

Posted on by
Reply

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

Posted on by
Reply

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.

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

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

Posted on by
Reply

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

Posted on by
Reply

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?

Posted on by
1

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?

Posted on by
Reply

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:

Lessons learned from building software at scale

Posted on by
Reply

So you have read The Lean Startup. Suffered through following several agile blogs (such as this one). You think you are ready to join the cool kids and have product scrums and stand-up meetings and all that other stuff. Now you need an implementation plan.

Maybe it is time to read this post by Paul Adams on the Intercon blog. He describes some of the lessons he and his development team have learned from building software and scaling it up as the company grows. I asked a few of my contacts at startup software firms what they thought of the post and there was mostly general agreement with his methodology.

Here are some of Adams’ main points to ponder.

Everyone has a different process, and the process itself changes as the company matures and grows. But his description is for their current team size of four product managers, four software designers, and 25 engineers. Like he says: “it’s not how we worked when we had a much smaller team, and it may not work when we have doubled our team.”

Create a culture where you can make small and incremental steps with lots of checkpoints, goals, and evaluations. “We always optimize for shipping the fastest, smallest, simplest thing that will get us closer to our objective and help us learn what works.” They have a weekly Friday afternoon beer-fueled demo to show how far they have gotten in their development for the week. Anyone can attend and provide comments.

Facetime is important. While a lot of folks can work remotely, they find productivity and collaboration increases when everyone is in the same room in a “pod.” Having run many remote teams, certainly local pods can be better but if you have the right managers, you can pull off remote teams too. It appears IBM is moving in this “local is better” mode lately.

Have small teams and make them strictly accountable. Adams has a series of accountability rules for when something goes wrong. Create these rules and teams and stick by them. “We never take a step without knowing the success measurement,” said one friend of mine, who agrees with much of what Adams says in his post. My friend also mentions when using small teams, “not all resources have a one-to-one relationship in terms of productivity; we find that we that the resources we use for prototyping new features can generally float between teams.”

Have a roadmap but keep things flexible and keep it transparent. “Everything in our roadmap is broken down by team objective, which is broken down into multiple projects, which in turn are broken down into individual releases,” said Adams. They use the Trello collaboration tool for this purpose, something that can either be a terrific asset or a major liability, depending on the buy-in from the rest of the team and how faithful they are to keeping it updated.

However, caution is advised: “The comprehensive approach that Adams describes would be entirely too much overhead for most startups,” says my friend. This might mean that you evaluate what it will take to produce the kind of detail that you really need. And this brings up one final point:

Don’t have too many tools, though. “Using software to build software is often slower than using whiteboards and Post-it notes. We use the minimum number of software tools to get the job done. When managing a product includes all of Google Docs, Trello, Github, Basecamp, Asana, Slack, Dropbox, and Confluence, then something is very wrong.”

Everyone is now a software company (again)

Posted on by
3

Several years ago I wrote, “everyone is in the software business. All of the interesting business operations are happening inside your company’s software.” Since then, this trend has intensified. Today I want to share with you three companies that should come under the software label. And while you may not think of these three as software vendors, all three run themselves like a typical software company.

The three are Tesla, Express Scripts, and the Washington Post. It is just mere happenstance that they also make cars, manage prescription benefits and publish a newspaper. Software lies at the heart of each company, as much as a Google or a Microsoft.

In my blog post from 2014, I talked about how the cloud, big data, creating online storefronts and improving the online customer experience is driving more companies to act like software vendors. That is still true today. But now there are several other things to look for that make Tesla et al. into software vendors:

  • Continuous updates. One of the distinguishing features of the Tesla car line is that they update themselves while they are parked in your garage. Most car companies can’t update their fleet as easily, or even ever. You have to bring them in for servicing, to make any changes to how they operate. Tesla’s dashboard is mostly contained inside a beautiful and huge touch LED screen: the days of dedicated dials are so over. These continuous updates are also the case for The Washington Post website, so they can stay competitive and current. The Post posts more total articles than the NYTimes with double the reporting staff of the DC-based paper. That shows how seriously they take their digital mission too.
  • These companies are driven by web analytics and traffic and engagement metrics. Just like Google or some other SaaS-based vendor, The Washington Post post-Bezos is obsessed with stats. Which articles are being read more? Can they get quicker load times, especially on mobile devices? Will readers pay more for this better performance? The Post will try out different news pegs for each piece to see how it performs, just like a SaaS vendor does A/B testing of its pages.
  • Digital products are the drivers of innovation. “There are no sacred cows [here, we] push experimentation,” said one of the Post digital editors. “It is basically, how fast do you move? Innovation thrives in companies where design is respected.” The same is true for Express Scripts. “We have over 10 petabytes of useful data from which we can gain insights and for which we can develop solutions,” said their former CIO in an article from several years ago.
  • Scaling up the operations is key. Tesla is making a very small number of cars at present. They are designing their factories to scale up, to where they can move into a bigger market. Like a typical SaaS vendor, they want to build in scale from the beginning. They built their own ERP system that shortens the feedback loop from customers to engineers and manages their entire operations, so they can make quick changes when something isn’t working. You don’t think of car companies being so nimble. The same is true for Express Scripts. They are in the business of managing your prescriptions, and understanding how people get their meds has become more of a big data problem. They can quickly figure out if a patient is following their prescription and predict the potential pill waste if they aren’t. The company has developed a collection of products that tie in an online customer portal to their call center and mobile apps.

I am sure you can come up with other companies that make normal stuff like cars and newspapers that you can apply some of these metrics to. The lessons learned from the software industry are slowly seeping into other businesses, particularly those businesses that want to fail fast and more quickly as their markets and customers change.