Welcome!

Java IoT Authors: Automic Blog, Liz McMillan, Elizabeth White, Pat Romanski, Roger Strukhoff

Related Topics: Java IoT

Java IoT: Article

Strategies for Securing Java Code

Anticipate and protect every possible security vulnerability

Java security is an overwhelming issue. For a truly secure application, you need to prevent hackers from entering the system, and you need to ensure that code safeguards security if a hacker does break in. Moreover, there is no room for error. If you anticipate and prevent hundreds of security vulnerabilities but overlook just one, a hacker can still wreak havoc on your system.

This article introduces some fundamental strategies for writing Java code that remains secure if a hacker manages to enter the system. Essentially, writing secure code requires a shift in thinking. Instead of worrying about whether code works correctly, you need to anticipate all of the ways that it can be exploited, then ensure that security is maintained in every possible worst case scenario. This, of course, is a monumental task, and there is no silver bullet for security. Several strategies for developing Java code that resists many common attacks are:

  • Follow coding guidelines for preventing security attacks
  • Code defensively to prevent hackers from propagating through the code
  • Expose and correct as many bugs as possible
Follow Coding Guidelines to Prevent Security Attacks
Ensuring that your code complies with the following coding rules can make your code less vulnerable to security attacks.

Rule 1: Avoid using inner classes
Java bytecode has no concept of inner classes, so the compiler translates inner classes into ordinary classes that are accessible to any code in the same package. An inner class gets access to the fields of the enclosing outer class - even if these fields are declared private - and the inner class is translated into a separate class. To let this separate class access the fields of the outer class, the compiler silently changes these fields' scope from private to package. As a result, when you use inner classes, not only is the inner class exposed, but the compiler is silently overruling your decision to make some fields private.

Note: If you really need to use inner classes, be sure to make all inner classes private.

Here is sample code that violates this rule:

package examples.rules.security;

public class AUIC {

    private class AUIC2 {  // VIOLATION
    }
}

To correct this code, make the class AUIC2 a top-level class as follows:

public class AUICF {

}

class AUIC2 {  // FIXED

}

Rule 2: Avoid comparing class objects by name
This rule prohibits comparing class objects with the getName() method. More than one class in a running JVM may have the same name. As a result, a hacker can create a class with malicious code and give it the same name as your class. When you compare classes by name, the comparison would not recognize this difference. When you compare classes by object equality, the difference would be detected.

Here is sample code that violates this rule:

package examples.rules.security;

public class CMP {
    public boolean sameClass (Object o) {
        Class thisClass = this.getClass();
        Class otherClass = o.getClass();
        return (thisClass.getName() == otherClass.getName());  //VIOLATION
    }
}

To correct this code, modify it as follows to directly compare thisClass and otherClass for equality:

package examples.rules.security;
public class CMP {
    public boolean sameClass (Object o) {
        Class thisClass = this.getClass();
        Class otherClass = o.getClass();
        return (thisClass == otherClass);  // FIXED
    }
·}

Rule 3: Make your classes noncloneable
This rule requires that you make classes nonclone-able by defining a final method clone that will throw a java.lang.CloneNotSupportedException(). For example:

public final Object clone() throws java.lang.CloneNotSupportedException {
throw new java.lang.CloneNotSupportedException();
}

Java's object cloning mechanism can allow an attacker to manufacture new instances of classes that you define, without executing any of the class's constructors. Even if your class is not cloneable, the attacker can define a subclass of your class, make the subclass implement java.lang.Cloneable, then create new instances of your class by copying the memory images of existing objects. By defining the above clone method, you'll prevent such attacks.

Note: If you really need to make your classes cloneable, be sure to make your clone() method final.

Rule 4: Make your classes nonserializable
This rule requires that if you want to prevent access to the internal state of your objects, make your class nonserializable. If you don't, your objects can be serialized into readable byte arrays. As a result, hackers can view the objects' full internal state, including private fields and the internal states of referenced objects.

To make a class nonserializable, define the final method writeObject() that throws an IOException. For example:

private final void writeObject (ObjectInputStream in)
|| throws java.io.IOException {
throw new java.io.IOException ("Class cannot be serialized");
}

This method is declared final so that a subclass defined by a hacker adversary cannot override it.

Note: If you need to make a class serializable, follow these tips to safeguard security:

  • Use the Transient keyword for fields that contain direct handles to system resources and other sensitive information.
  • Do not pass an internal array to any DataInput/DataOutput method that takes an array when defining your own serializing method for a class.
The source for these tips is "Secure Programming for Linux and Unix HOWTO" by David Wheeler (www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/java.html).

Rule 5: Do not depend on package scope
This rule prohibits classes with public or package-private access. An attacker can simply add another class to your package and then access package-private fields that were supposed to be hidden.

To correct violations of this rule, modify code so that it does not rely on package-level access. Give your classes, methods, and fields the most restricted access possible. If this is not an option, you might want to use package sealing, which can prevent hackers from adding classes to a package that is in a "sealed" JAR file. Package sealing is discussed at http://java.sun.com/j2se/1.3/docs/guide/extensions/spec.html#sealing.

Rule 6: Avoid returning references to mutable objects and, if necessary, clone the mutable object before returning a reference to it
Mutable objects are objects whose states can be changed. When you return a reference to a mutable object, the caller can change the state of that object; if that object is used in the class later on, it will be using a different state of the object, which would affect the internals of the class.

Note that arrays are mutable (even if array contents are not mutable), so don't return a reference to an internal array with sensitive data.

Here is sample code that violates this rule:

         // fDate is a Date Field.

         // The caller of this method can change the Date object and
         // affect the internals of this class.
         public Date getDate() {
             return fDate;
         }

To correct this code, modify it to return a defensive copy of the field as follows:

public Date getDate() {
    return new Date(fDate.getTime());
}

Now, the caller of this method can change the returned Date object without affecting the internals of this class.

Rule 7: Make methods, fields, and classes private; if there's a reason one should not be private, document that reason
If a class, method, or variable is not private, hackers could use it as a potential entry point. If there is a good reason why a method, field, or class should not be private, it does not need to be private, but that reason should be clearly documented.

Rule 8: Make all classes and methods final; if there is a reason one should not be final, document that reason
If a class or method is not final, hackers could try to extend it in an unsafe way. If there is a good reason why a method or class should not be final, it does not need to be final, but that reason should be clearly documented.

Coding Defensively to Prevent Hackers from Moving Through the Code
Another way to boost code security is to code defensively by implementing defensive software firewalls and validating user/external inputs.

Defensive software firewalls have many uses, one of which is to ensure that any hacker who manages to access your code cannot move through critical code sections. A defensive software firewall is a point in the logical flow of a program where the validity of logical constraints is checked. If a constraint specified in a firewall is satisfied, execution proceeds. If the constraint is violated, the firewall triggers, generates an appropriate error message, and possibly takes damage-control actions (such as stopping execution) or diagnostic actions (such as turning on debugging information). Firewalls should not alter the execution flow of a program unless they are triggered, and they should have either no effect or a negligible effect on the performance of the production version.

Note that these firewalls are not related to the firewalls placed around Internet connections. The concept discussed here relates solely to code construction. If designed carefully, these firewalls serve the same purpose as physical firewalls: they can contain a dangerous event and prevent it from causing a complete disaster.

In Java, firewalls can be implemented by adding assertions that say that if the program reaches a critical point without executing the expected operations, the program should throw exceptions, shut down, or perform another defensive action. Hackers often access code from a path that you didn't know existed or did not expect to be taken. By using firewalls to check whether critical program points were reached in unexpected ways, you can identify many attempted security breaches and stop hackers from entering and manipulating your most critical code.

To implement these firewalls with assertions, first determine the critical points in your code, then add assertions so that when each critical point is reached, the call stack is checked to verify that the program reached that critical point by executing the expected sequence of operations. When a critical point is reached through an unexpected sequence of operations, the program should throw an exception and terminate. Once this firewall is implemented, you will have a barrier that prevents hackers from using "backdoor paths" to gain entry into your most critical code.

For example, the code in Listing 1 could be added to verify the call stack before modifying a field in the database. In this case, the assertTrue method is assumed to accept an error message and a boolean. If the boolean is false, the message with an exception will be reported and the program will terminate.

Another defensive coding strategy is to validate all user/external input. When security is an issue, you should always worry about external inputs. If users manage to submit the "right" inputs, they could gain access to program details you hoped to keep private, prompt the application to crash or enter an unstable state, or access and modify the database. These inputs could be created by hackers trying to design inputs that cause a security breach (for example, by applying a technique known as SQL injection, where hackers submit inputs designed to create a strategic SQL string, such as a string that disables password checking, a string that adds a new account, etc.). Moreover, these inputs could also be submitted by well-meaning users who entered information incorrectly (as a result of a typo or a copy/paste error) or who simply misunderstood what type or format of information they were supposed to add.

By validating all external inputs, you can identify improper or malicious inputs as they are submitted and then prevent the program from using those inputs. The performance impact and user inconvenience will be minimal, especially if you consider the potential impact and inconvenience of having the application unavailable or functioning incorrectly because a hacker designed and successfully submitted the "perfect" input.

User input validation could be performed with assertions, Design by Contract, or if statements. For example, say you have the following method that accepts a filename as input from a user, but does not verify whether the filename represents a valid file.

void method (String filename) {
System.exec("more " + filename);
}

If the user passes filename = "joe; /bin/rm -rf /*", the execution of that method could delete files. If the application runs as a regular user, the spawned process (rm -rf) inherits its privileges, which means that the user can remove only the files for which he or she has modify permissions. If the application runs as root, the spawned process will inherit root privileges and all files on the hard drive can be removed.

To prevent hackers from performing such disastrous deletions, this method should verify whether the entered filename represents a valid file. This verification could be implemented as a simple check using an if statement as follows:

void method (String filename){
if (new File(filename).exists()){
System.exec("more " + filename);
}
}

Expose and Correct as Many Bugs as Possible
Every bug that you are not aware of could present hackers with an opportunity to exploit your system. Each bug represents unexpected program behavior; if the program is not behaving as you expect, how can you rest assured that it is not providing hackers with a way to manipulate your code?

Java code that throws unexpected, uncaught runtime exceptions is especially ripe for security breaches. Imagine that when one of your methods receives an input that you did not expect, it throws an uncaught runtime exception that's thrown up several layers in your call stack before it's handled, and the handling code exposes some critical Java code. If a hacker can produce this exception (for example, by flooding that method with a wide variety and range of inputs), he or she can then learn about the critical code.

The best way to expose these types of problems is to perform what is known as "white-box testing" or "construction testing." This testing involves designing inputs that thoroughly exercise a class's public methods, then examines how the code handles the test inputs.

For example, if you wanted to check whether uncaught runtime exceptions could cause a class to expose critical code in methods you think are protected, you would flood the class's exposed methods with a wide variety of inputs to try to flush out all possible exceptions, examine how the class responds to each exception, and modify the code so that it does not throw dangerous exceptions.

If you find errors during the testing phase, you have the opportunity to fix the problem before an actual security breach occurs. In fact, this type of testing is best performed at the unit level because testing each unit (each class) in isolation is the best way to expose the maximum number of errors. Because unit testing brings you much closer to the errors, it helps you detect errors that application-level testing does not always find. Take a closer look at Figures 1 and 2 to see how unit testing does this.

Figure 1 shows a model of testing an application containing many units. The application is represented by the large oval, and the units it contains are represented by the smaller ovals; external arrows indicate inputs; starred regions show potential errors.

To find errors in this model, you modify inputs so that interactions between units force some units to hit the potential errors. This is incredibly difficult. Imagine standing at a pool table with a set of billiard balls in a triangle at the middle of the table, and having to use a cue ball to move the triangle's center ball into a particular pocket - with one stroke. This is how difficult it can be to design an input that finds an error within an application. As a result, if you rely only on application testing, you might never reach many of your application's units, let alone uncover the errors they contain.

As Figure 2 illustrates, testing at the unit level offers a more effective way to find errors. When you test one unit apart from all other units, reaching potential errors is much easier because you are much closer to those errors. The difficulty of reaching the potential errors when the unit is tested independently is comparable to the difficulty of hitting one billiard ball into a particular pocket with a single stroke.

To expose the maximum number of errors that pose security threats, you need to exercise the code as fully as possible. Unit-level testing is the ideal mechanism for doing this.

Design by Contract
Design by Contract (DbC) can be used to validate user inputs as well as to implement firewall-like restrictions that prevent hackers from moving through the application. DbC was designed to express and enforce contracts between a piece of code and its caller; these contracts specify what the callee expects and what the caller can expect.

Typically, DbC is implemented by expressing the code's implicit contracts in terms of assertions. Three types of conditions commonly used to create contracts are:

  • Preconditions: To express conditions that must hold true before a method can execute
  • Postconditions: To express conditions that must hold true after a method completes
  • Invariants: To express conditions that must hold true any time a client can invoke an object's method
Java tools that support DbC generally have you incorporate specification information into comment tags and then instrument the code with a special compiler to create assert-like expressions out of the contract keywords. When the instrumented code is executed, contract violations are typically sent to a monitor or logged to a file. The degree of program interference varies. You can often choose between nonintrusive monitoring (problems are reported, but program execution is not affected), having the program throw an exception when a contract is violated, or hand-coding custom actions.

To learn more about DbC, see the following resources:

  • Plessel, T. "Design By Contract: A Missing Link In The Quest For Quality Software": www.cs.unc.edu/~smithja/MIMS/DataModel/research/DBC.html
  • Interactive Software Engineering. Building Bug-Free O-O Software: An Introduction to Design by Contract: www.eiffel.com/doc/manuals/technology/contract/page.html

    Conclusion
    Following the strategies mentioned in this article will protect your Java code from many common security attacks. However, these strategies should be viewed as the beginning of a thorough security strategy, not as a security panacea. You need to anticipate and protect every possible security vulnerability because just one vulnerability can allow a skilled or lucky hacker to steal classified information or make your application unavailable. To ensure security, you need to learn how to identify and repair additional security vulnerabilities; some places to start are:

  • Compaq. Extended Static Checking for Java, SQL Injection Walkthrough: www.securiteam.com/securityreviews/5DP0N1P76E.html
  • Graff, M.G., and van Wyk, K.R. (2003). Secure Coding Principles and Practices. O'Reilly.
  • Howard, M., and LeBlanc, D. (2002). Writing Secure Code. Microsoft Press.
  • Kolawa, A., Hicken, W., and Dunlop, C. (2001). Bulletproofing Web Applications. John Wiley & Sons.
  • McGraw, G., and Felten, E. (1999). Securing Java. John Wiley & Sons: www.securingjava.com
  • Rao, R. (1999). Writing Secure Java Code. Macmillan Technical Publishing.
  • Sun Microsystems. Security Code Guidelines: http://java.sun.com/security/seccodeguide.html
  • Viega, J., McGraw, G., Mutdosch, T., and Felten, E. "Statically Scanning Java Code: Finding Security Vulnerabilities." IEEE Software (Sept./Oct. 2000).
  • More Stories By Adam Kolawa

    Adam Kolawa is the co-founder and CEO of Parasoft, leading provider of solutions and services that deliver quality as a continuous process throughout the SDLC. In 1983, he came to the United States from Poland to pursue his PhD. In 1987, he and a group of fellow graduate students founded Parasoft to create value-added products that could significantly improve the software development process. Adam's years of experience with various software development processes has resulted in his unique insight into the high-tech industry and the uncanny ability to successfully identify technology trends. As a result, he has orchestrated the development of numerous successful commercial software products to meet growing industry needs to improve software quality - often before the trends have been widely accepted. Adam has been granted 10 patents for the technologies behind these innovative products.

    Kolawa, co-author of Bulletproofing Web Applications (Hungry Minds 2001), has contributed to and written over 100 commentary pieces and technical articles for publications including The Wall Street Journal, Java Developer's Journal, SOA World Magazine, AJAXWorld Magazine; he has also authored numerous scientific papers on physics and parallel processing. His recent media engagements include CNN, CNBC, BBC, and NPR. Additionally he has presented on software quality, trends and development issues at various industry conferences. Kolawa holds a Ph.D. in theoretical physics from the California Institute of Technology. In 2001, Kolawa was awarded the Los Angeles Ernst & Young's Entrepreneur of the Year Award in the software category.

    More Stories By Gina Assaf

    Gina Assaf is a systems
    engineer at Parasoft.
    She has been developing, designing, testing, and
    implementing applications
    in Java for nearly six years.
    She has researched and
    developed many of the coding standards, many of which
    provide security for Java
    applications. Assaf has a
    BS in computer science.

    More Stories By Roberto Scaramuzzi

    Roberto Scaramuzzi is a software engineer at Parasoft. He grew up professionally as a Perl developer, but is now also adept at Java and PHP. Roberto holds a PhD in mathematics.

    Comments (3) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Stuart Thiel 03/26/05 10:08:52 AM EST

    While I would agree with the previous comment I read that some of the suggestions seem to be to ignore good programming practices, I feel this only applies to the first half of the article. The second half of the article actually brings up some good points and suggests the use of some technologies that are currently under-utilized. Namely DbC, and all the goodies that come with/around it.

    My research group happens to be looking at related technologies, and we're interested in experienced programmers describing how they feel such tools should interact with the code and the developers when faced with anomalies during runtime. Granted, our approach is not concerned with security, the gains we make for development overlap directly with many of the issues described in the second half of this article. To that end, it'd be great if other people reading this article, specifically those interested in the last half, would fill out a short survey we've developed about various forms of runtime checking.

    The survey is here:
    https://www.dsrg.org/ASN_Survey/index.html

    Chris Arnold 06/16/04 05:19:24 PM EDT

    I am concerned that this article encourages developers to ignore sound Java design and programming principles in the name of security. However, this article seems to be based on information that is from 1999 (five years old)! I wonder if many of these "threats" are still valid.

    Furthermore, since most of these "threats" seem to be in response to a hacker gaining access to the virtual machine, aren''t these precautions moot (couldn''t someone with full access to a virtual machine make private fields public, for example)?

    I hate to see us circumvent powerful features of the Java programming language in the name of, what may be, security "urban legends" (I''m not a security expert -- I wish the authors and JDJ would have given more of a basis for their article).

    David Biesack 05/18/04 03:07:39 PM EDT

    Rule 4 says (for serialization) to make writeObject final "so that a subclass ... cannot override it".

    However, private methods cannot be overridden; the final
    keyword does nothing to a private method. A subclass
    which defines its own writeObject method will not prevent
    this class'' writeObject method from running; the JVM will call all writeObject methods (until one throws an exception). Thus, simply throwing the exception is sufficient for making an object non-serializable. (The
    base class writeObject method will run before the subclass writeObject)

    More pertinent would be to make

    ANY-ACCESS-MODIFIER Object writeReplace()

    a final method.

    @ThingsExpo Stories
    Nordstrom is transforming the way that they do business and the cloud is the key to enabling speed and hyper personalized customer experiences. In his session at 21st Cloud Expo, Ken Schow, VP of Engineering at Nordstrom, discussed some of the key learnings and common pitfalls of large enterprises moving to the cloud. This includes strategies around choosing a cloud provider(s), architecture, and lessons learned. In addition, he covered some of the best practices for structured team migration an...
    Recently, REAN Cloud built a digital concierge for a North Carolina hospital that had observed that most patient call button questions were repetitive. In addition, the paper-based process used to measure patient health metrics was laborious, not in real-time and sometimes error-prone. In their session at 21st Cloud Expo, Sean Finnerty, Executive Director, Practice Lead, Health Care & Life Science at REAN Cloud, and Dr. S.P.T. Krishnan, Principal Architect at REAN Cloud, discussed how they built...
    In his session at 21st Cloud Expo, Raju Shreewastava, founder of Big Data Trunk, provided a fun and simple way to introduce Machine Leaning to anyone and everyone. He solved a machine learning problem and demonstrated an easy way to be able to do machine learning without even coding. Raju Shreewastava is the founder of Big Data Trunk (www.BigDataTrunk.com), a Big Data Training and consulting firm with offices in the United States. He previously led the data warehouse/business intelligence and B...
    In his Opening Keynote at 21st Cloud Expo, John Considine, General Manager of IBM Cloud Infrastructure, led attendees through the exciting evolution of the cloud. He looked at this major disruption from the perspective of technology, business models, and what this means for enterprises of all sizes. John Considine is General Manager of Cloud Infrastructure Services at IBM. In that role he is responsible for leading IBM’s public cloud infrastructure including strategy, development, and offering m...
    With tough new regulations coming to Europe on data privacy in May 2018, Calligo will explain why in reality the effect is global and transforms how you consider critical data. EU GDPR fundamentally rewrites the rules for cloud, Big Data and IoT. In his session at 21st Cloud Expo, Adam Ryan, Vice President and General Manager EMEA at Calligo, examined the regulations and provided insight on how it affects technology, challenges the established rules and will usher in new levels of diligence arou...
    The 22nd International Cloud Expo | 1st DXWorld Expo has announced that its Call for Papers is open. Cloud Expo | DXWorld Expo, to be held June 5-7, 2018, at the Javits Center in New York, NY, brings together Cloud Computing, Digital Transformation, Big Data, Internet of Things, DevOps, Machine Learning and WebRTC to one location. With cloud computing driving a higher percentage of enterprise IT budgets every year, it becomes increasingly important to plant your flag in this fast-expanding busin...
    Smart cities have the potential to change our lives at so many levels for citizens: less pollution, reduced parking obstacles, better health, education and more energy savings. Real-time data streaming and the Internet of Things (IoT) possess the power to turn this vision into a reality. However, most organizations today are building their data infrastructure to focus solely on addressing immediate business needs vs. a platform capable of quickly adapting emerging technologies to address future ...
    No hype cycles or predictions of a gazillion things here. IoT is here. You get it. You know your business and have great ideas for a business transformation strategy. What comes next? Time to make it happen. In his session at @ThingsExpo, Jay Mason, an Associate Partner of Analytics, IoT & Cybersecurity at M&S Consulting, presented a step-by-step plan to develop your technology implementation strategy. He also discussed the evaluation of communication standards and IoT messaging protocols, data...
    22nd International Cloud Expo, taking place June 5-7, 2018, at the Javits Center in New York City, NY, and co-located with the 1st DXWorld Expo will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud ...
    22nd International Cloud Expo, taking place June 5-7, 2018, at the Javits Center in New York City, NY, and co-located with the 1st DXWorld Expo will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud ...
    DevOps at Cloud Expo – being held June 5-7, 2018, at the Javits Center in New York, NY – announces that its Call for Papers is open. Born out of proven success in agile development, cloud computing, and process automation, DevOps is a macro trend you cannot afford to miss. From showcase success stories from early adopters and web-scale businesses, DevOps is expanding to organizations of all sizes, including the world's largest enterprises – and delivering real results. Among the proven benefits,...
    @DevOpsSummit at Cloud Expo, taking place June 5-7, 2018, at the Javits Center in New York City, NY, is co-located with 22nd Cloud Expo | 1st DXWorld Expo and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to wait...
    Cloud Expo | DXWorld Expo have announced the conference tracks for Cloud Expo 2018. Cloud Expo will be held June 5-7, 2018, at the Javits Center in New York City, and November 6-8, 2018, at the Santa Clara Convention Center, Santa Clara, CA. Digital Transformation (DX) is a major focus with the introduction of DX Expo within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive ov...
    SYS-CON Events announced today that T-Mobile exhibited at SYS-CON's 20th International Cloud Expo®, which will take place on June 6-8, 2017, at the Javits Center in New York City, NY. As America's Un-carrier, T-Mobile US, Inc., is redefining the way consumers and businesses buy wireless services through leading product and service innovation. The Company's advanced nationwide 4G LTE network delivers outstanding wireless experiences to 67.4 million customers who are unwilling to compromise on qua...
    SYS-CON Events announced today that Cedexis will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 - Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Cedexis is the leader in data-driven enterprise global traffic management. Whether optimizing traffic through datacenters, clouds, CDNs, or any combination, Cedexis solutions drive quality and cost-effectiveness. For more information, please visit https://www.cedexis.com.
    SYS-CON Events announced today that Google Cloud has been named “Keynote Sponsor” of SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Companies come to Google Cloud to transform their businesses. Google Cloud’s comprehensive portfolio – from infrastructure to apps to devices – helps enterprises innovate faster, scale smarter, stay secure, and do more with data than ever before.
    SYS-CON Events announced today that Vivint to exhibit at SYS-CON's 21st Cloud Expo, which will take place on October 31 through November 2nd 2017 at the Santa Clara Convention Center in Santa Clara, California. As a leading smart home technology provider, Vivint offers home security, energy management, home automation, local cloud storage, and high-speed Internet solutions to more than one million customers throughout the United States and Canada. The end result is a smart home solution that sav...
    SYS-CON Events announced today that Opsani will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Opsani is the leading provider of deployment automation systems for running and scaling traditional enterprise applications on container infrastructure.
    SYS-CON Events announced today that Nirmata will exhibit at SYS-CON's 21st International Cloud Expo®, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Nirmata provides a comprehensive platform, for deploying, operating, and optimizing containerized applications across clouds, powered by Kubernetes. Nirmata empowers enterprise DevOps teams by fully automating the complex operations and management of application containers and its underlying ...
    SYS-CON Events announced today that Opsani to exhibit at SYS-CON's 21st Cloud Expo, which will take place on October 31 through November 2nd 2017 at the Santa Clara Convention Center in Santa Clara, California. Opsani is creating the next generation of automated continuous deployment tools designed specifically for containers. How is continuous deployment different from continuous integration and continuous delivery? CI/CD tools provide build and test. Continuous Deployment is the means by which...