Tag: development cycle

  • Network Resilience and Security from A to Z

    Network Resilience and Security from A to Z

    An observer watching a bunker shot by legendary pro golfer Gary Player was heard to say: “I’ve never seen anyone so lucky in my life.” The player retorted: “Yes, and the more I practice, the luckier I get.” Yet, when it comes to cybersecurity, nearly half of organizations are solely relying on luck to get them through a cyberattack.

    There is not enough practice or training in terms of incident response, and testing happens haphazardly depending on the developer and organization—obfuscating baselines and the context necessary to ensure security and resilience. Particularly in terms of testing, we’ve noticed that despite awareness of its importance, bugs and vulnerabilities routinely slip through. In fact, a recent Ixia survey found that 34 percent of developers have deployed products that have had a few bugs. Worse, 31 percent said products harbored significant vulnerabilities that required patching later in the cycle when shipped.

    The problem has been exacerbated by the rapidly growing normalization of agile development processes. Groups of developers are tasked to build products piecemeal, leading to application development that is often incremental and happens in iterative cadences. Testing and oversight happen at each step of the process, but the segmented nature of the development cycle means that bugs and vulnerabilities often arise when the code is assembled, and are routinely missed. For instance, the average IT web application had 32 vulnerabilities, according to recent WhiteHat Security report. It’s clear that more than a local test—a comprehensive end-to-end test—and relevant training are critical.

    A Change in Culture

    Improvement begins by changing the culture that minimizes security testing for the sake of launch timelines. Too often, the product development team will come together just to be told they need to move up their release date. The habit results in products that walk a thin line of performance, as they may contain unknown security holes due to not being fully tested. Just consider the slew of IoT devices and services that have been proven to be vulnerable because of this habit—from cars to coffee machines to cameras. It’s a major reason for security incidents, even with multiple layers of security tools.

    This also requires the right training. Having seemingly secure code and the right security measures is not enough for a strong security stance if proper training is not implemented. Organizations need to learn how to respond. Yet, recent SANS Institute research into the incident response capabilities of companies worldwide found that 43 percent of respondents did not have a formalized incident response plan, and 55 percent didn’t even have an incident response team.

    This less-than-vigilant approach to system-level security can have worse implications once a product goes live in the network. For instance, updates, patches and configuration changes applied when a new feature is added can reset an organization’s security posture, and this sometimes goes unnoticed—leaving gaps for threat actors to exploit. Or sometimes a machine fails to update and becomes and entry point, as experienced by JPMorgan Chase. Continuous testing and training from the very onset of operation and throughout a tools lifespan are imperative for all employees, especially IT and security pros—even in its simplest iterations.

    What to Look For

    Successful and continuous testing and training expose security and IT pros to anomalous activity they’d not be able to recognize otherwise. It’s necessary to be able to answer questions such as, “What does suspicious activity look like on my network?” or “What security alerts require immediate action?” The more they see, the more refined their eye becomes—it’s all about a proactive approach paired with repetition.

    Which raises the question, what is considered a good test? It starts with accurately reflecting the widest range of attack types in live operation. It is also important to create an accurate sandbox to test in so that it can be as close to reality as possible. The more accurate the environment, the better prepared IT and security teams will be. Realistic depictions better prepare employees as new malware, phishing and DDoS attack types emerge every day—not to mention it helps keep up with evolving typical application behavior.

    More specifically, function and system testing should be at the heart of any program following the development cycle test process. Quality of service, performance and resilience all benefit, along with security, as a result.

    Some companies take shortcuts, such as using internally generated attacks or crowdsourced probes to attack their networks. Just as bad, some have the development team create and run their own test scenarios. While this can give the illusion that everything is good, it creates a false sense of security—a single scenario only protects you from one type of attack.

    The key is not to stop at the minimum when it comes to security testing and training. Developers spend lots of time building great features; why not spend time training teams on how to use them? Limited or biased tests can easily overlook glaring flaws.

    Ultimately, the right approach to testing can make networks robust and prepare IT teams for real-world attack situations, helping minimize response times and the negative impact on the business. As breaches now seem to be coming from every direction, testing needs to come to the foreground, from the development stages to when products sit directly in the line of fire.

    About the Author / Jeff Harris

    jeffharrisJeff Harris is VP, Solutions at Ixia, leading solutions marketing for Ixia’s security portfolio of products and capabilities. As a former product development leader of advanced networking, communications, and surveillance products for commercial and military applications, Jeff has a deep appreciation for security implications that occur in development and operation. Jeff has led first to market product teams in personal area networks, mobile ad hoc networks, and a wide range of surveillance equipment and platforms. Connect with him on LinkedIn and Twitter.

  • 3 Ways Manual Processes are Risking Your Development Cycle

    3 Ways Manual Processes are Risking Your Development Cycle

    During my two decades in IT, I’ve seen the demand for Agile and its associated methodologies grow. At the same time, however, I’ve witnessed the database being left behind.

    DBmaestro, where I am co-founder and CTO, recently conducted a survey titled, “Database Deployment & Development Risks,” to gain insights into the risks associated with various database development practices. The survey focused on manual processes used throughout the development cycle.

    The results revealed two divergent realities: Despite respondents, from diverse sectors, overwhelmingly recognizing the risks associated with manual process for the database, many organizations continue to use processes and solutions that don’t fully automate the development cycle.

    One area where this was particularly apparent was with the source control. It’s imperative that development teams are able to trust their source control. But even when standard source control solutions are being utilized, 70 percent of those surveyed are still interjecting manual processes.

    What that means is that even though many of these professionals have some type of solution, they still see a clear and present risk because:

    1. When integrating changes, it’s possible for one developer to wrongly override valid changes with older revisions from other development branches, a potential concern that nearly 90 percent of survey respondents associate with risk. Still, more than half (53 percent) of the IT professionals surveyed integrate changes, creating the possibility that such overrides may occur.

    Nearly three-fourths (70 percent) reported having a database source control, but 53 percent reported that they continue to have problems that a more adequate source control solution should resolve. In this case, there is a problem with the source control tool implemented.

    2. The database may not be in sync with the version control repository. Ninety percent of the IT professionals surveyed associated the potential for these sources to be out of sync with risk. What’s more, 72 percent of those surveyed admit that their database may not be in full sync with the version control repository.

    3. Introducing changes without first verifying each database object vs. its version control revision to ensure each database object is up to date is a process that nearly 90 percent of survey participants associate with risk. Despite a widespread awareness that failing to verify accuracy between database objects and database source control before introducing changes is a risky practice, 53 percent continue to do so.

    That means that the remaining 47 percent of respondents do not trust their source control solution regarding the database code and are implementing steps to validate it matches the database before introducing changes.

    While interjecting manual steps can help alleviate the risk associated with the possibility of overriding critical changes in the database, it’s time-consuming, and manual interruptions to the continuous delivery cycle introduce risks of their own. When you can’t place full trust in source control, two developers working on the same database code or objects can easily override or revert critical changes introduced by the other developer when the script is updated in the database—sometimes with disastrous consequences.

    Only a Database Enforced Source Control solution that covers database lifecycle management (DLM) from development through build and deployment can create a “Single Source of Truth” for your database development assets. This allows you to gain trust in your source control and implement the rapid changes today’s development cycles demand—without plugging the process with time-consuming manual steps. Database Enforced Source Control promotes complete trust in your source code, allowing developers to work simultaneously on the same database objects without the risk of overriding important changes when scripts are updated, promoting true synchronization across dispersed development teams.

    Download the complete results of the 2015 “Database Deployment & Development Risks.”

    About the author:
    image001Yaniv Yehuda is the Co-Founder and CTO of DBmaestro, an Enterprise Software Development Company focusing on database development and deployment technologies. Yaniv is also the Co-Founder and the head of development for Extreme Technology, an IT service provider for the Israeli market. He was a captain in Mamram, the Israel Defense Forces computer centers, where he served as a software engineering manager.