855.519.7328
Image Post

Mobile App Development Policies

The Exploitation of Mobile Applications is on the Rise. Mobile applications, often referred to as apps, provide much needed convenience and functionality for today’s workforce. Developers across every industry vertical have created mobile applications for various uses and business requirement, which is contributing to the proliferation of modern mobile devices.

Image Post

State of the Union Sounded Like State of Security

SOTU State of Security (SOTU SOS)

While many pundits and political experts from the various news stations came across my television to speculate on the major topics our Commander-In-Chief would touch on during his State of the Union (SOTU) address, none thought he would focus as much attention as he did on the subject of Cybersecurity.

Understanding the obvious technological advancements we have made since President(s) Reagan, Bush Sr., and Bill Clinton were in office, it was somewhat shocking (and reassuring) to hear the President of the United States speak about the importance of preventing hackers from stealing Personally Identifiable Information (PII), taking a stance against identity theft, and protecting our children’s information from falling into the wrong hands via the World Wide Web.

Sure, as CEO of Praetorian Secure, my message to just about anyone who will listen focuses on these same topics, but for the “most powerful man in the free-world” to focus on it as a key part of the SOTU certainly would suggest it has presented itself as a major challenge for all people in all places.

In the past, several politicians (even this same President) have publicly acknowledged the need for cybersecurity improvements within the “critical infrastructure” of our nation, but I fail to recall an instance where anyone has managed to make it so personal. He spoke of common threats that affect the average citizen and not just the large business down the road. In fact, he spoke of establishing a national standard that would call for businesses to contact customers and aptly notify them when potential security breaches have occurred instead of remaining “tight lipped” and pointing the blame to another company and/or individual.

Another interesting aspect of his speech revolved around his statement “No foreign nation, no hacker, should be able to shut down our networks, steal our trade secrets, or invade the privacy of American families, especially our kids. We are making sure our government integrates intelligence to combat cyber threats, just as we have done to combat terrorism.”

This may seem very vague to the average citizen, I can honestly look upon as being an honest well intended statement of fact. As it so happens, for many years our federal government has had multiple compliance initiatives spanning across a variety of agencies with little to no reciprocation occurring between these same agencies. As an example, a system operating within the United States Air Force (USAF) would need to meet the Certification and Accreditation (C&A) requirements of the Department of Defense Information Assurance Certification and Accreditation Process (DIACAP /RMF), while this same system introduced into the Food and Drug Administration (FDA) would need to meet the certification requirements of NIST SP 800-53.

While many of the security controls from both bodies target the same end-goal of stronger security and risk management, the ability for these systems to co-exist within a “federal government network” proved impossible because the standards do not map directly with one another and the interpretation of some of the controls would return vastly different opinions. However, the federal government (and Department of Defense) have begun recently to shift their cybersecurity management over to the Risk Management Framework (RMF) which should allow for ALL agencies to share a common security requirement — thus allowing individual branches of the DoD and federal agencies such as the FDA, IRS, FBI, etc. to maintain a level playing field for security and improve the overall data communication within our countries government offices.

Last night I found myself putting political affiliation aside for a moment and listening to key statements and relevant information about the “state of our union” as it pertained to very familiar subject. The information shared gave me a sense of hope about how we plan to combat a global threat and how this is not just a matter of security for businesses, but for all of us. Now let’s just hope the President doesn’t appoint a “czar” to lead the charge!

Image Post

Application Risk Assessment 7-Steps

Application Risks

Application software development is sweeping our industry at an alarming rate. From organizations adopting various apps for iPhone, iPad, and Android platforms, to full-on internally developed applications to support their business and customer requirements. While the need for these applications increase, we are finding that the security technologies allowing for a solid Software Development Life-cycle (SDLC) are limited.

Over the years, we have seen a number of companies that have appropriate policies and procedures in place that would seem (from the surface at least) to address the security principles required for developing hardened applications. However, as with most “in-demand” aspects of our industry these security principles are being shortened and limited to meet delivery to the end-user and budgetary constraints. This has left me scratching my head on more than one occasion. Do organizations not realize the risk involved with developing applications without applying secure-coding principles?

Design for Security

Let’s be honest. Designing for security in software is futile unless you plan to act on the design and incorporate necessary secure controls during the development stage of your SDLC. It is imperative that secure features are not ignored when design artifacts are converted into syntax constructs that a compiler or interpreter can understand. Writing secure code is no different than writing code that is usable, reliable, or scale-able.

Test for Security

In addition, security testing should complement existing functionality testing. At a bare minimum, tests for common software vulnerabilities, such as overflow and injection flaws, and testing the behavior of software to unexpected and random input formats (fuzz testing) should be conducted in testing environments that emulate the configuration of the production environment.

Manage for Security Risk(s)

Designing and testing for security will only produce partial results. The reality is that every organization should define the security policies required for each application being developed. While this can be accomplished in a number of ways, we recommend following these steps:

 

  1. Assign a business impact level or assurance level” – High, medium, low, very low depending on business impact and consequences.
  2. Align application testing type with the stage in SDLC or lean development process – Integrate with you development process whatever it may be.
  3. Select appropriate analysis and scanning methods – Should your application require static analysis, automated dynamic testing, or penetration testing? Identifying the suitable method of analysis will prove to save valuable dollars all while meeting secure-coding principles.
  4. Use industry standard security scores – Using industry standards like the Common Weakness Enumeration (CWE) and Common Vulnerability Scoring System (CVSS) allow organizations to combine these standards into a meaningful and practical way to assess software security across internally and externally developed applications.
  5. Develop a process flow for fixing vulnerabilities and flaws – Assign roles and responsibilities for review and mitigation of flaws and threats.
  6. Define a remediation period for closing flaws based on priority – Few organizations can invest the resources to fix all vulnerabilities with equal priority, so an efficient system of triage is essential. The greatest risks, as a function of potential impact and likelihood of occurrence, should be re-mediated first.
  7. Keep an application portfolio score card – Gauge risk across all applications. Manage portfolio risk over-time.

Application Risk Assessment Conclusions

We all understand the pressures to add and test functionality within a compressed schedule. The key is to integrate a methodology for managing risk within the compressed development time-frame. With a few adjustments and investing in development of a lean process for integrating security all the operational and proper risk management practices can be included in application development.

If the issue is resources contact a third party consulting firm like Praetorian Secure to fill in the gaps. Security testing should not stop the process it is the means and pre-planning that will help manage your company reputation and increase security. Most of this type of testing can be integrated by a managed security testing company as an extension of your organization without loss time. Contact us for more information.

Image Post

Anti-Spam Law Forces Change at Microsoft

From Canada with Love: Canadian Anti-Spam Law Forces Change at Microsoft

A great many of us in the security industry have come to expect and rely on the monthly email messages from our friends at the Microsoft Corporation to provide us with helpful information on the various applications to be patched on the next “Patch Tuesday”. According to Microsoft, it appears that this is coming to an end, at least temporarily.

As of July 1, 2014, due to changing governmental policies concerning the issuance of automated electronic messaging, Microsoft is suspending the use of email notifications that announce the following:

Security bulletin advance notifications
Security bulletin summaries
New security advisories and bulletins
Major and minor revisions to security advisories and bulletins

In lieu of email notifications, you can subscribe to one or more of the RSS feeds described on the Security TechCenter website.

Before we go lashing out at Microsoft, it should be noted that this is reportedly being done in response to a new anti-spam law being introduced in Canada next month — though Microsoft has not confirmed this to be the reasoning behind the sudden freeze on the monthly messaging service.

As noted in the official message being sent by Microsoft, security personnel that would like to continue receiving these informative updates can subscribe to one or more of the RSS feeds from the Security TechCenter website.

Related Information:
Sign up to receive bulletins: http://technet.microsoft.com/en-us/security/dd252948
Search all security bulletins: https://technet.microsoft.com/security/bulletin

Image Post

Finding a Balance 3 Core Goals of IT Security?

We live in a world where everything seems to revolve around high-speed communication and the technology platforms that provide it. The business world is no different, in fact the very nature of conducting business these days is dependent upon how fast something can be implemented and how quickly can stake-holders access important data.

It is with this in mind that I pose a very relevant (and often forgotten) question: Which is most important in our world of technology and communication confidentiality, integrity, or availability? Don’t rush to answer just yet, after all, as an IT Leader your opinion probably doesn’t matter to your organization anyway (insert sarcastic smile).

Several years ago when my colleagues and I decided to start Praetorian Secure I remember thinking we would be able to change the world with our innovative approach to many compliance verticals and overall IT security strategies. However, something that somehow escaped my naivety was the fact that key business decision makers are often not concerned with security, and more so are focused on the mighty dollar. Now, as a business leader myself I understand why focusing on the budget and personnel is important – but I am also very cautious to never let the privacy, reliability, or timeliness of something be negatively impacted in the process. Perhaps our key leaders just require a refresher course on what the “CIA Triad” is all about?

Confidentiality

Confidentiality refers to limiting information access and disclosure to authorized users — “the right people” — and preventing access by or disclosure to unauthorized ones — “the wrong people.” Confidentiality is related to the broader concept of data privacy — limiting access to individuals’ personal information. This is covered in several U.S. federal & state laws and quite extensively in various compliance mandates such as HIPAA, FISMA, and FERPA.

Integrity

Integrity refers to the trustworthiness of information and resources. It includes the concept of “data integrity” — namely, that data has not been changed inappropriately, whether by accident or deliberately malign activity. It also includes “origin” or “source integrity” — that is, that the data actually came from the person or entity you think it did, rather than an imposter.
On a more restrictive view, however, integrity of an information system includes only preservation without corruption of whatever was transmitted or entered into the system, right or wrong.

Availability

Availability refers, unsurprisingly, to the availability of information resources. An information system that is not available when you need it is at least as bad as none at all. It may be much worse, given the reliance most organizations have based on a functioning computer and communications infrastructure. Many could literally not operate without them.
Availability, like other aspects of security, may be affected by purely technical issues (e.g., a malfunctioning part of a computer or communications device), natural phenomena (e.g., wind or water), or human causes (accidental or deliberate).

Let’s Find a Balance

Security efforts to assure confidentiality, integrity and availability can be divided into those oriented to prevention and those focused on detection. The latter aims to rapidly discover and correct for lapses that could not be — or at least were not — prevented. The balance between prevention and detection depends on the circumstances, and the available security technologies. For example, while locked doors and windows have proven over the years to be easily compromised, if we only relied on an alarm to protect our loved ones and belongings we would have only implemented an effective detection method against home invasion.
It is critical to remember that “appropriate” or “adequate” levels of confidentiality, integrity and availability depend on the context, just as does the appropriate balance between prevention and detection. The nature of the efforts that the information systems support; the natural, technical and human risks to those endeavors; governing legal, professional and compliance standards — all of these need to be considered and will condition how you, not only answer my question above, but also how the CIA standards are effectively implemented throughout the enterprise.

Image Post

6 Commonly Believed Myths About PCI DSS

As a PCI QSA, and having maintained security credentials allowing me to perform audits for various IT regulatory compliance initiatives, I have found myself engaged in multiple conversations with organizations who are buying into the commonly believed myths about PCI DSS compliance.

PCI DSS is certainly no exception to the rule when it comes to regulatory compliance standards being misunderstood.  While (in my opinion) the PCI Security Standards Council (SSC) does pretty well at providing standards and supporting materials to enhance payment card data security for merchants, service providers, and acquirers, we are contacted almost weekly by organizations confused on what they are classified as, and what their potential requirements are.

In addition, we are brought in quite frequently to either confirm and/or deny organizational myths about whether PCI DSS applies to them, or if “skimping” on requirements could lead them to potential security breaches.  With that in mind, I have compiled my personal top six  list of commonly believed myths about PCI DSS.

Top 6 List of Commonly Believed Myths PCI DSS

 

#6 Our Company is compliant with PCI DSS because we utilize PCI DSS compliant applications.  – First of all, applications and/or systems cannot be considered PCI DSS compliant, only organizations can achieve compliance.  The proper terminology is Payment Application Data Security Standard compliant.

Secondly, utilizing a PA DSS compliant application does not guarantee and organization to be PCI DSS compliant, rather it is simply demonstrating support of PCI DSS requirements and ensuring the application(s) is managed in accordance with PCI DSS guidelines. Even if the application is PA DSS compliant during testing the application still needs to be installed in accordance with the vendor’s instructions to maintain the compliance.  PCI QSA’s generally still include the application in the scope of the PCI DSS validation.

#5 If our organization experiences a security breach, the certificate of compliance will protect us against penalties, fines, and other legal ramifications.-  While I have heard many QSA’s make this statement to customers, the reality is that is not necessarily true.  Once a security breach has been recorded many “after-action” type activities begin.   One of the main exercises is that of a forensic investigation.  With this investigation it will be further determined how the breach occurred and in the end how it could have been prevented.  Once the investigation is completed, these forensic reports will be provided to the card brands and they will actually make a final determination on whether or not your company is liable for the breach of credit card data.  In reality, the certificate of compliance you had prior to the security breach is of little use during the forensic process.

#4 If we outsource our card processing we will be PCI DSS compliant. – Outsourcing simplifies payment card processing but does not provide automatic compliance. Don’t forget to address policies and procedures for cardholder transactions and data processing. Your business must protect cardholder data when you receive it, and process charge backs and refunds. You must also ensure that providers’ applications and card payment terminals comply with respective PCI DSS standards and do not store sensitive cardholder data. You should request a certificate of compliance annually from providers.

#3 Our third-party contract calls out PCI DSS compliance from our prime; however, we are still delaying to gauge the effort and they have not made it an issue.  Our scope of credit card data is small as a service provider. – Delaying.The fact of the matter is your organization is engaged in storing, processing, and/or transmitting credit card data.  The liability should compel you to take action to mitigate the risk to your company’s reputation and the financial well-being of the company you work for.  Our recommendation would be to start off with a PCI DSS risk assessment and initial PCI QSA review.  The PCI DSS risk assessment and review will identify your potential threats and PCI DSS weaknesses that can later be used in a prioritized approach to implementing PCI DSS.  Delay tactics with contracts in place create bigger relationship problems and could be the downfall of your organizations reputation with customers and business partners.

#2 Our organization is too small to be required to maintain PCI DSS compliance. – PCI is applicable to any size of business. If you take even 1 credit card a year, you need to be PCI compliant. Business can only flourish if proper infrastructure is established such as Human Resources, Marketing, Customer Service, etc. In the same way PCI Compliance is something that should be setup and considered as a key ingredient of your business infrastructure as may likely be essential in how you gather payments and process customer information.

#1 We are PCI DSS compliant, therefore we are secure! – This has to be the number one misconception of any regulatory compliance requirement, and it simply is not true!  In fact, I cannot tell you the number of times we have had security engineers discover significant security flaws with “compliant” customers.   In addition, even the PCI SSC recognizes this to be a fact, and have documented it in their own “Myths of PCI Compliance” as follows “successful completion of system scan or assessment for PCI is but a snapshot in time.   Security exploits are non-stop and get stronger every day, which is why PCI compliance efforts must be a continuous process of assessment and remediation to ensure safety of cardholder data.”

The above list is only a partial capture of some of the most common myths we hear from customers and comrades in the field.  PCI DSS is not a safe harbor against potential credit card data breaches, nor is it a requirement reserved for only large companies.  The fact with PCI DSS is that it is a regulatory compliance standard that when implemented and maintained correctly can improve organizational security posture, provide customer(s) confidence your protection their credit card data, reduce financial risks, and reduce threats that could cause a breach of cardholder data.

Image Post

6 Cybersecurity Goals in Federal Acquisition Process

Federal Government Acquisition Standards to Involve Cybersecurity

In January of this year the Department of Defense (DoD), in cooperation with the General Services Administration (GSA) announced they would be implementing a cybersecurity and resilience program for the Federal Acquisition System. As part of this announcement, the program would call for six planned reforms to strengthen the current security posture and ultimately combat risks to the Federal Acquisition System.

Initially, I was thinking this may be another failing attempt to bring security to our government systems, but after further investigation, I believe this is a positive step forward with the Risk Management Framework (RMF) that has been adopted. While past programs have focused on the security of systems and components, it appears the federal government may be leaning heavily on the DoD’s DIACAP structure and expanding their concerns to people, processes, and the technology in use. A pure “management of risk” in my opinion.

6 Cybersecurity Goals for DoD and GSA Acquisition

While we are far from seeing a full-blown implementation of these reforms and/or RMF, the report released by the DoD/GSA focuses on six reforms that align cybersecurity initiatives with the current federal acquisition process:

  1. Institute baseline cybersecurity requirements as a condition of contract award for appropriate acquisitions. – Making this a contract requirement prior to contract award may prove to push “commercial” organizations into the adoption of a NIST-based RMF and further improve security for all US-based organizations.
  2. Include cybersecurity in acquisition training – This is something that should have been done years ago. As a former government IT employee, I can’t tell you the number of times that contracts were awarded based on price, and not based on the merit, capability, and security of the awardee.
  3. Develop common cybersecurity definitions for federal acquisitions – Everyone speaking the same language. Our federal government has almost made it impossible for sister-agencies to conduct business with one another because of the various guidelines and varying requirements from one agency to the next. Having a common platform and definitions for risk management and overall security will prove to enhance operations, and introduce the reciprocity many of us have longed to receive.
  4. Institute a federal acquisition cyber risk management strategy – This is in direct relation to the RMF game plan, and should strengthen not only the federal contracts it will oversee, but also keeps our national security as a top priority. While I will refrain from pointing out any questionable contract awards from the past, having a systematic way of measuring risk during the acquisition process is something that should protect all stakeholders involved.
  5. Include a requirement to purchase from original equipment manufacturers, their authorized re-sellers, or other trusted sources – How is this not already a requirement? Do some of our federal agencies not have a Configuration Control Board (CCB) that reviews and permits software/hardware procurement’s? This will should improve the reliability of goods/services and save significant budgetary dollars in the process.
  6. Increase government accountability for cyber risk management – This is the one aspect that has been lacking in many contracts I have been involved with. While the federal government loves to “pass the buck”, many times they end up paying the price for a security-breach. IF implemented correctly, this aspect will strengthen government contracts, and essentially be the mainstay of the cybersecurity reform.

What Cybersecurity Improvements Are Expected?

The reforms listed above will be implemented by using a structured approach and involve stakeholder engagement, utilizing a repeatable process to address cyber risks in the development, acquisition, sustainment, and disposal life-cycles for all Federal procurement’s. The implementation will also harmonize the recommendations with existing risk management processes under Federal Information Security Management Act and OMB guidance.

As with most cybersecurity initiatives sponsored by the federal government, this adoption will take some time to develop, but I can honestly say that we seem to be heading in the right direction. As we progress there will most likely be some shifts and modifications to the overall plan, but taking a proactive stance to security instead of the reactive approach we are so used to experiencing is far more inviting.

Image Post

Effective Asset Management for Compliance & Security

Asset Management  for Enterprise Security

In efforts to improve the security posture of an organization, it is often important to gain greater control and efficiency when managing assets—technology systems, software, documentation, and employees. One of the problems we continually find with some of our customers cardholder data environment (CDE) is their ability to keep an accurate inventory of the various components involved. Maintaining an up-to-date CDE and keeping track of all of the systems can become more challenging than initially thought.

In today’s business world, organizations find themselves juggling an ever-increasing number of hardware and software products, and keeping a proper system component inventory can seem like more trouble than it’s worth—however, this plays a significant role in the establishing and control of an information systems security plan. It is also required by the PCI Data Security Standard (PCI DSS) under Requirement 2.4.

Asset Management Benefits Compliance

PCI DSS requires PCI-compliant businesses to “maintain an inventory of system components that are in scope for PCI DSS.” Below are some general recommendations that should prove effective at maintaining an accurate inventory and compliance with PCI DSS.

 

  • Discovery Scanning – Performing periodic asset discovery & inventory scanning will allow for your organization to enumerate all of your in-scope PCI systems.
  • Personnel Interview(s) – Polling and interviewing relevant personnel can help to ensure the software and hardware inventory is being tracked efficiently and updated appropriately.
  • Standard of Service – Identify how the assets are to perform and to what condition. This should include the various parts of the asset system or group (a simple performance specification).
  • Proof of Concept – Many organizations struggle with simply starting an inventory management program. For this reason, most companies could benefit greatly from performing a walkthrough or proof of concept. This will help to narrow your requirements and better understand the various components required for an effective asset management program.

 

With a wide-variety of tools and management systems available to assist with this process, often it is beneficial to contract a third-party to perform an analysis of the environment and discovery scanning. In addition, this is even more crucial for organizations attempting to meet or maintain compliance regulations such as PCI DSS, HIPAA, DIACAP/NIST and Sarbanes-Oxley as it will confirm the in-scope assets to be regulated.

 

When contracting a third-party to support your team with asset management and compliance scoping it is important you factor in the following:

 

  • Proper Budgeting – Establish a budget that accounts for your organizational goals and compliance requirements.
  • Develop a Plan –Ensure the organization performing the assessment is aware of the organizational objectives you wish to accomplish with the tracking of assets (e.g., Regulatory compliance, security improvement(s), etc.). This will prove to establish what needs to be tracked, how systems should be managed, and key personnel involved with these systems.
  • Policy – Reputable organizations should have not only the experience required to assist with asset management, but most should also have examples of policies or best business practices that can be modified and/or adopted by your organization.

 

With an accurate Inventory Management program organizations will be better prepared for deploying security techniques and technologies, implementing compliance requirements, and tracking systems through their entire life-cycle.  In addition, having an effective control on system inventory will inevitably save on organizational resources and the financial burden experienced due to improper scoping.

Image Post

5 Tips for Secure Software and Mobile Application Development

 

5 Tips for Secure Software and Mobile Application Development

 

In our line of work, the majority of our security engineering and consulting resides with network and system(s) security.  This in no way downplays the importance of security in other sectors of the IT business, but I can only report the facts as they are known to me.  However, as of late, we have noticed a significant shift in customer requests focusing on security of their applications and the security-posture maintained through the development of these applications.

OWASP has maintained and reported their Top 10 list for many years, but as of late it appears more and more organizations are starting to pay extra attention to its importance and the impact some of these vulnerabilities could have on their applications and business.  Whether the reason be the increasing mobile applications, regulatory compliance, or plain recognition of the security importance involved – companies are finally starting to realize areas for improvement and requiring more due diligence in identifying potential threats.

While secure coding practices should be instituted and built-in to the lifecycle of every application developed, this is not always the case.  Where this becomes alarmingly clear is with the development of mobile applications.  The IT industry as a whole is equally guilty of lacking the patience we try to sell to our customers and this same “I want it now” mentality is starting to show with the development of mobile applications into the work-force.

Mission Critical or Convenient

One of my favorite terms used for permitting a “slight” side-step of security is “mission critical”.  This term was adopted from our military and somehow managed to become the “catch-all” excuse for an application or system lacking in proper security configuration(s).   Is it really about something being “mission critical” or is it about the application making tasks more convenient?

With mobile apps being developed at an intense clip for a wide-variety of purposes, the focus should be on the security rather than the convenience.  Given the very nature of a mobile app makes them extremely vulnerable to external attacks.  Show me one teenager without a foundational understanding of “jail-breaking” an Android or iPhone and I will be shocked.    With an ability to jail-break a device, experienced individuals are literally allowed root access, flexibility in application downloads, phone configuration that would otherwise be locked, and access to compiled application files which turns  into something far “less convenient” for your user-community and upper-management.

Mobile Application Connections

With mobile applications, one constant is the connection status of the app itself.  For a mobile application to have industry credibility it typically needs to be serving an enterprise service or providing a work function not found otherwise.  This requires connection to internal servers.  Given the jail-break scenario mentioned previously, it stands to reason that individuals could easily gain access to internal business resources through any application vulnerability.  This is certainly a major concern for developers (at least it should be) and determination on types of connections to internal resources should be determined at the early stages of application development.

Security Checklists for Mobile App Development

Internally we maintain a well-established process and methodology for reviewing software and mobile application development for our clients.  While I won’t venture into the depths of our security review processes, I thought it best for this particular article to highlight some important aspects.

  1. Secure It Early.  Simply putting security as a main focus early on in the development process of your application will reduce the risk of potential vulnerabilities encountered.  Establishing a software review board or Change Control Board (CCB) will likely produce a secure code development process that is effective at reducing both the risks associated to mobile applications and cost for recovering from an exposed vulnerability.
  2. What’s Your Policy?  Something that is often overlooked in the development of mobile applications are the internal privacy and information systems policy of a given organization.  In addition, more and more companies are faced with requirements and mandates stemming from regulatory compliance (such as HIPAA, PCI DSS, NIST, etc.) and need to consider all of these factors in the planning and design stages of the application development process.
  3. Let’s Be Honest.  I cannot tell you the number of times we have worked with clients who have explained their application security design and review process is handled internally and most of the time by the same team developing the application(s).  Being fully aware of budgetary constraints facing a large portion of companies these days, this is one area that should involve serious consideration for investment. Without going so far as to accuse all software developers of being ill-willed or mischievous,  the simple fact is that not inviting an experienced third-party to analyze, assess, and test applications early on in the design process is asking for potential problems down the road — which will prove very costly and could impact public persona.
  4. Study for the Test.  Nothing could be more damming for the success of an application than failing to meet its intended purpose for development.  Additionally, nothing could be more damming to your business as a non-secure mobile application serving its workforce.  This is the reason that testing and documenting the various tests performed is very crucial to the success of your team.  With industry-proven tools, well planned test cases, and third-party security companies this can be addressed rather easily and save time, money, and resources in the end.
  5. Let’s Roll.  Having successfully maneuvered through the 4 previous steps, you should be well on your way to officially presenting your application to the user-community and deploying as required.  While security was effectively addressed and considered throughout the process explained above, the initial deployment of your application should involve heavy over-sight and management from either an internal or external security team to ensure application integrity.

 

Security is a 24/7 operation and should be seriously considered in every aspect of your business.  New threats and vulnerabilities are being discovered at an all-time rate and taking the necessary precautions now can save you from disastrous consequences later.  With that in mind, appropriate training of key personnel should be maintained and ultimately be required on at least an annual basis.  This will allow for future development life cycles to operate at a more efficient and effective rate.

Praetorian Secure follows an industry-proven methodology for secure software and mobile application development, and for more information regarding our Software Security Services, please contact us at 855-510-7328 or click here to fill out our online customer form.

Image Post

Defense-In-Depth Six Steps to Protecting Information Technology Assets

Defense in Depth: Applying Multiple Layers of Security for Protecting Business Assets

As a former U.S. Marine, I can remember many of sleepless nights and early morning exercises practicing with our unit to establish our defense position(s), and fortify our camp-site perimeter against the enemy.  While going through the exercise I can also remember knowing that the enemy we were “guarding” against was another Marine-unit just like our own, who was very prepared for what we were about to throw against them.  However, no matter how well prepared they were for defenses, the more “layers” of it we established, the slower their assault became…..thus leading to us being able to apply a remarkable defense of our position.

Defense-in-Depth for Cybersecurity

One thing that remains a constant for security practitioners around the globe is that today’s threats are ever-evolving, and persistent.   In addition to this, security engineers also have to face threats originating from multiple places, in multiple forms, and with a wide-variety of targets.  Protecting your business assets has quickly surpassed the days of simply updating your anti-virus or installing patches.  Defense-In-Depth strategy by definition is providing multiple layers of protection for multiple threats. With it, each layer of protection is designed to address a specific type of threat and if one security measure is bypassed or fails, the next layer steps in to defend the system.

Implementation of Defense-in-Depth

Deploying multiple security measures to an existing infrastructure takes a great deal of planning, resources, and often financial commitment.  However, if taken in steps any organization can layer their security and improve their overall security posture without much financial impact or the need for high-impact/high cost solutions.

 

Step One – Security Starts with Personnel

 

Security must start with the employees.  End-users are the backbone of security to an enterprise environment and must be involved with, and informed about security practices and policies.  Properly training and understanding of employees role in relation to security can be very effective.  Develop Acceptable Use Policies that formally assign security responsibilities.  Communicate policies for notification when a user observes improper behavior or receives suspicious emails. Awareness in your user base can improve understanding of the importance of security and be effective in early response to potential malicious activity.

 

Step Two – File it Away

 

An often overlooked aspect of security is actually built-into every operating system utilized in today’s business world.  File-level protection can be managed and proven valuable (especially for smaller budgets) in protecting critical business information. Apply appropriate permissions to protect confidentiality and integrity with role based access considerations.  Log access to files and monitor users to ensure permissions are effective. Implement appropriate backup and recovery capabilities.

 

Step(s) Three & Four – Do We Have a Patch for that Virus?

 

I like to pair these two separate security measures together because in some ways they become dependent of one another.  While an anti-virus solution protects against unwanted bugs from penetrating our networks, it requires periodic updates to protect against the latest threat.  The same can be said about many of the applications running on our business networks.  Failure to properly patch applications can lead to the same disastrous consequences as failing to update your anti-virus.  The first step is developing a patch management process and metric that drives timelines for patching security risks.  The process should also addresses patches by priority and severity.  As always patches should be tested before implementation to reduce risks of impacting system availability.

 

Step Five – Fire on the Perimeter

 

Many harmful incidents can be prevented at the perimeter of our networks.  I cannot tell you how many times my colleagues and I have performed an incident review or security-breach analysis only to find that the incident could have been prevented if the firewalls in place had been properly patched and/or configured.  Firewall rules should deny by default and permit by exception.  Performing periodic review of your network perimeter devices and rules on a yearly basis is a practice that pays dividends.  Additionally, on a regular basis validate network device configurations to ensure they have not drifted from the directives specified by your configuration standards.

 

Step Six – What Size Monitor is that?

 

Our final step in implementing easy (yet successful) defense-in-depth solutions is monitoring.  Almost everything that infects, corrupts, or breaches our security can be detected if proper monitoring is being practiced.  Whether it is manual review of system log files or obtaining services from a low-cost Managed Security Service Provider (MSSP), such as Praetorian Secure (insert small company plug), 24/7 protection can be gained and detection of threats can be real-time.

As you can see, development of a Defense-in-Depth strategy doesn’t have to be an overwhelming task with an astronomical budget.  When done carefully and correctly, many organizations can implement a layered defense quickly and affordably.  Some of the best implementations of Defense-In-Depth strategy are based on routine risk evaluation and prioritizing layered defenses to impact risk reduction.

I have realized many parallels between the cybersecurity “Defense-in-Depth” approach, and that of the “layered-defenses” implemented by my military brethren.   Now, as CEO of Praetorian Secure, I am faced with many sleepless nights and early morning exercises thinking of new and creative ways to protect some of our customer’s most sensitive assets.  While our counterparts trying to attack from the outside are no longer “friendly”, the majority of them are highly-skilled and “very prepared for what we are about to throw against them.”  Now, if we slow them down enough with multiple layers of security, what a “remarkable defense of our position” we will have.