As software continues to pervade our lives, the security of that software continues to grow in importance. We need to keep private data private. We need to protect financial transactions and records. We need to protect online services from infiltration and attack.
We can obtain this protection through ‘Application Security,’ which is all about building and delivering software that is safe and secure. Developing software within an integrated toolchain can greatly enhance security.

read more

There is no more effective way to reduce your overall test environment spend than to migrate to cloud test environments and embrace testing and infrastructure automation. The nature of test environments is inherently temporary—you set up an environment, run through an automated test suite, and then tear down the environment. If you can reduce the cycle time for this process down to hours or minutes, then you may be able to cut your test environment budgets considerably.

read more

Cloud platforms like Azure provide the best options for organizations in their digital transformation. Most organizations have multiple combination of environment needs. Provisioning on time is always a challenge. Manual operations are prone to error and delays.
Difficult to size production like Environments due to resource constraints, this means most NFR (Non Functional Requirements) are not tested with the correct load and perspective.

read more

Adoption and use of cloud-based software engineering platforms will accelerate in 2017. Teams have been working in the cloud for a few years now, but in 2017, the trend will gain far more momentum as senior engineering staff and service providers realize and document the benefits of cloud-based development gains. Adoption will not be limited to open source or Microsoft solutions as all software engineering tool stacks are moving quickly to catch the adoption wave. Leading application lifecycle management companies are already delivering enhanced SaaS platforms for issue and backlog management, source code management, IDEs and testing, allowing for greater control among and between teams and environments. The elimination of «well, it worked on my machine» or «we fixed that bug last release» can be achieved by well-integrated and managed SaaS software engineering environments.

read more

Even though software as a service (SaaS) is more mature than its infrastructure as a service (IaaS) and platform as a service (PaaS) brethren – and therefore at a lower growth rate – new figures from Synergy Research show that Microsoft leads the ‘burgeoning’ market ahead of Salesforce, with Oracle and Google having the highest growth rates.

Despite the relatively low growth forecast, Synergy argues that the enterprise SaaS market is expected to double in size over the next three years with ‘strong’ growth across all segments and regions.

ERP, with SAP, Oracle and Infor at its top, will have the highest growth rate with almost 40% year on year revenue growth, ahead of collaboration – headed up by Microsoft, Cisco and Google – HR, and CRM, with the latter going at a mere 20% yearly growth. The overall market, the analyst firm argues, hit almost $13 billion in quarterly revenues.

“There are a variety of factors driving the SaaS market which will guarantee substantial growth for many years to come,” said Synergy research director John Dinsdale. “Traditional enterprise software vendors like SAP, Oracle and IBM are all pushing to convert their huge base of on-premise software customers to a SaaS subscription relationship; meanwhile, relatively new cloud-based vendors like Workday and Zendesk are aggressively targeting the enterprise market, and industry giants Microsoft and Google are on a charge to grow their subscriber bases, especially in the collaboration market.”

An example of the former was SAP’s announcement around a ‘new generation of intelligent cloud ERP’ last month which aims to help customers adopt business processes based on real-time insights through artificial intelligence (AI). Part of Oracle’s aggressive growth came in the form of acquiring NetSuite, announced in July last year and completed in November. At the time, Dinsdale told this publication that while the deal would naturally strengthen Oracle’s offering in ERP SaaS, it would also boost its CRM status, although remaining a ‘long way’ behind Salesforce and Microsoft.

Even though software as a service (SaaS) is more mature than its infrastructure as a service (IaaS) and platform as a service (PaaS) brethren – and therefore at a lower growth rate – new figures from Synergy Research show that Microsoft leads the ‘burgeoning’ market ahead of Salesforce, with Oracle and Google having the highest growth rates.

Despite the relatively low growth forecast, Synergy argues that the enterprise SaaS market is expected to double in size over the next three years with ‘strong’ growth across all segments and regions.

ERP, with SAP, Oracle and Infor at its top, will have the highest growth rate with almost 40% year on year revenue growth, ahead of collaboration – headed up by Microsoft, Cisco and Google – HR, and CRM, with the latter going at a mere 20% yearly growth. The overall market, the analyst firm argues, hit almost $13 billion in quarterly revenues.

“There are a variety of factors driving the SaaS market which will guarantee substantial growth for many years to come,” said Synergy research director John Dinsdale. “Traditional enterprise software vendors like SAP, Oracle and IBM are all pushing to convert their huge base of on-premise software customers to a SaaS subscription relationship; meanwhile, relatively new cloud-based vendors like Workday and Zendesk are aggressively targeting the enterprise market, and industry giants Microsoft and Google are on a charge to grow their subscriber bases, especially in the collaboration market.”

An example of the former was SAP’s announcement around a ‘new generation of intelligent cloud ERP’ last month which aims to help customers adopt business processes based on real-time insights through artificial intelligence (AI). Part of Oracle’s aggressive growth came in the form of acquiring NetSuite, announced in July last year and completed in November. At the time, Dinsdale told this publication that while the deal would naturally strengthen Oracle’s offering in ERP SaaS, it would also boost its CRM status, although remaining a ‘long way’ behind Salesforce and Microsoft.

If you’re considering migrating your business applications to a public cloud, the chances are that you’ve looked into Amazon Web Services. With its higher capacity and wide range of cloud services, AWS has become the most popular choice for businesses looking to take advantage of the scalability and cost-effective storage that cloud computing offers.

Security in AWS is based on a shared responsibility model: Amazon provides and secures the infrastructure, and you are responsible for securing what you run on it.  This model gives you greater control over your traffic and data, and encourages you to be proactive. However, before migrating your applications to AWS, here are some tips on how to manage and enforce security for maximum protection across your AWS and on-premise environment

Understanding security groups

Amazon offers a virtual firewall facility for filtering the traffic that crosses your cloud network segment; but the way that AWS firewalls are managed differs slightly from the approach used by traditional firewalls.  The central component of AWS firewalls is the ‘security group’, which is essentially what other firewall vendors would call a policy, i.e. a collection of rules.  However, there are key differences between security groups and traditional firewall policies that need to be understood.

Firstly, in AWS, there is no ‘action’ in the rule stating whether the traffic is allowed or dropped.  This is because all rules in AWS are positive and always allow the specified traffic – unlike traditional firewall rules. 

Secondly, AWS rules let you specify the traffic source, or the traffic destination – but not both on the same rule. For Inbound rules, there is a source that states where the traffic comes from, but no destination telling it where to go.  For Outbound rules it the other way around: you can specify the destination but not the source. The reason for this is that the AWS security group always sets the unspecified side (source or destination, as the case may be) as the instance to which the security group is applied.

Thirdly, AWS is flexible in how it allows you to apply these rules. Single security groups can be applied to multiple instances, in the same way that you can apply a traditional security policy to multiple firewalls.  AWS also allows you to do the reverse: apply multiple security groups to a single instance, meaning that the instance inherits the rules from all the security groups that are associated with it.  This is one of the unique features of the Amazon offering, allowing you to create security groups for specific functions or operating systems, and then mix and match them to suit your business’ needs.

Managing outbound traffic

AWS does manage outbound traffic, but there are some differences in how it does this compared to conventional approaches that you need to be aware of.  With AWS, the user is not automatically guided through the settings for outbound traffic during the initial setup process.  The default setting is that all outbound traffic is allowed, in contrast to the default setting for inbound traffic which deniesall traffic until rules are created.

Clearly, this is an insecure setting which can leave your organisation vulnerable to data loss, so it’s advisable to create rules that allow only specific outbound traffic, and protect data that is truly critical.  Because the AWS setup wizard doesn’t automatically take you through the outbound settings, you will need to create these rules manually and apply them. 

Auditing and compliance

Once you start using AWS in production, you need to remember that these applications are now subject to regulatory compliance and internal audits. Amazon does offer a couple of built-in features that help with this: Amazon CloudWatch, which acts as a health monitor and log server for your instances, and Amazon CloudTrail, which records and audits your API calls. However, if you are running a hybrid data centre environment, you will require additional compliance and auditing tools.

Depending on which industry you’re in and what type of data you handle, your business will be subject to different regulations – for example, if you process credit card information, you will be subject to PCI. So if you want to use your AWS cloud platform for this sensitive data, then you will need the right third-party security management products in place to provide you with the same reporting facilities that you would get with a conventional firewall.

The most important thing you need from a third-party solution is visibility of the policies from all security groups and of your whole hybrid estate, together with the same analysis and auditing capabilities as an on-site infrastructure, to give you a holistic view and management of your security environment.

Ultimately, it is your responsibility to secure everything that you put onto an AWS environment.  Considering these points and following the steps I’ve outlined will help to ensure that you protect your data and comply with regulatory requirements when migrating to AWS.

Read more: How to achieve HIPAA compliance on AWS: A guide

If you’re considering migrating your business applications to a public cloud, the chances are that you’ve looked into Amazon Web Services. With its higher capacity and wide range of cloud services, AWS has become the most popular choice for businesses looking to take advantage of the scalability and cost-effective storage that cloud computing offers.

Security in AWS is based on a shared responsibility model: Amazon provides and secures the infrastructure, and you are responsible for securing what you run on it.  This model gives you greater control over your traffic and data, and encourages you to be proactive. However, before migrating your applications to AWS, here are some tips on how to manage and enforce security for maximum protection across your AWS and on-premise environment

Understanding security groups

Amazon offers a virtual firewall facility for filtering the traffic that crosses your cloud network segment; but the way that AWS firewalls are managed differs slightly from the approach used by traditional firewalls.  The central component of AWS firewalls is the ‘security group’, which is essentially what other firewall vendors would call a policy, i.e. a collection of rules.  However, there are key differences between security groups and traditional firewall policies that need to be understood.

Firstly, in AWS, there is no ‘action’ in the rule stating whether the traffic is allowed or dropped.  This is because all rules in AWS are positive and always allow the specified traffic – unlike traditional firewall rules. 

Secondly, AWS rules let you specify the traffic source, or the traffic destination – but not both on the same rule. For Inbound rules, there is a source that states where the traffic comes from, but no destination telling it where to go.  For Outbound rules it the other way around: you can specify the destination but not the source. The reason for this is that the AWS security group always sets the unspecified side (source or destination, as the case may be) as the instance to which the security group is applied.

Thirdly, AWS is flexible in how it allows you to apply these rules. Single security groups can be applied to multiple instances, in the same way that you can apply a traditional security policy to multiple firewalls.  AWS also allows you to do the reverse: apply multiple security groups to a single instance, meaning that the instance inherits the rules from all the security groups that are associated with it.  This is one of the unique features of the Amazon offering, allowing you to create security groups for specific functions or operating systems, and then mix and match them to suit your business’ needs.

Managing outbound traffic

AWS does manage outbound traffic, but there are some differences in how it does this compared to conventional approaches that you need to be aware of.  With AWS, the user is not automatically guided through the settings for outbound traffic during the initial setup process.  The default setting is that all outbound traffic is allowed, in contrast to the default setting for inbound traffic which deniesall traffic until rules are created.

Clearly, this is an insecure setting which can leave your organisation vulnerable to data loss, so it’s advisable to create rules that allow only specific outbound traffic, and protect data that is truly critical.  Because the AWS setup wizard doesn’t automatically take you through the outbound settings, you will need to create these rules manually and apply them. 

Auditing and compliance

Once you start using AWS in production, you need to remember that these applications are now subject to regulatory compliance and internal audits. Amazon does offer a couple of built-in features that help with this: Amazon CloudWatch, which acts as a health monitor and log server for your instances, and Amazon CloudTrail, which records and audits your API calls. However, if you are running a hybrid data centre environment, you will require additional compliance and auditing tools.

Depending on which industry you’re in and what type of data you handle, your business will be subject to different regulations – for example, if you process credit card information, you will be subject to PCI. So if you want to use your AWS cloud platform for this sensitive data, then you will need the right third-party security management products in place to provide you with the same reporting facilities that you would get with a conventional firewall.

The most important thing you need from a third-party solution is visibility of the policies from all security groups and of your whole hybrid estate, together with the same analysis and auditing capabilities as an on-site infrastructure, to give you a holistic view and management of your security environment.

Ultimately, it is your responsibility to secure everything that you put onto an AWS environment.  Considering these points and following the steps I’ve outlined will help to ensure that you protect your data and comply with regulatory requirements when migrating to AWS.

Read more: How to achieve HIPAA compliance on AWS: A guide