Machine Learning on local devices still is not real machine learning. The article refers to iPhoneX’s new chip and the “CoreML” SDK. Unfortunately, training the ML model still has to occur somewhere else.

ML requires training a model to recognize inputs. It’s impossible to create one ML Model to recognize all possible real world situations, so it’s necessary to continue collecting data, “retrain” the model, and redeploy the updated model.

For anyone who’d rather not ship all of their information to someone else’s cloud, we’re still years away from real ML capabilities for our own devices.

If anyone knows of an available ML solution that can perform continuous training/learning on a local device, I’d love to hear about it.

http://flip.it/xqvU3i

Advertisements

Overview of privacy concerns with iPhoneX FaceID (and other facial recognition utilities). The note that companies have been patenting abilities to recognize emotions (and health) should raise concerns.

ByTheWay… you don’t have to own one of these devices to have your privacy violated… simply being in range of someone else’s camera opens the door to abusive companies.

http://flip.it/ZdEzf0

Brand Hijacking: doppelgänger domains, typo squatting, and counterfeit apps

Does your cyber security program address doppelgänger domains, typo squatting, and counterfeit apps?Organizational impersonation (brand hijacking) uses your reputation to dupe a victim. These attacks never hit your firewalls.  

Let that sink in. A brand impersonation/hijacking attack is unlikely to touch any of you apps, websites, networks, firewalls, or logs. It occurs completely outside of and independent of any resources under your organizational control.

Fortunately, basic defenses against these kind of risks can be implemented with rather simple tools; yet, this topic is overlooked by many organizations and security teams. Yet, it yields a two for one benefit… the same practices that reduce risks of brand hijacking are also applicable to verify the apps and services your organization consumes from others are legitimate and secure.

Who assesses your security configuration management practices?

Who assesses your security configuration management practices?

In follow up to Security Misconfiguration is the #5 risk in 2017.

Are assessments an internal processes? Do you rely on auditors (often an adversarial experience for staff)? Do you rely on Pentests and vulnerability scans (often limited in scope)? Or wait for the post-mortem after an event occurs?

If these options seem lacking, perhaps its time to consider adding a 3rd party assessment to your security program.  A few of the benefits include:

  • reduced burden on Security Operations team.
  • fresh perspectives and insights.
  • assistance preparing for Audits.
  • determination if scope of Pentests and Vulnerability Scans are appropriate and adequate.
  • evaluation of Security Configuration Management practices.  If needed, can provide coaching (or assistance) in establishing configuration management.
  • an SOW thats right for you and the current needs of your organization, not driven by the agenda of an auditor or a product vendor.

Even if your organization is not bound by regulations requiring specific security measures or audits, you may want to be proactive about your organization’s security health for more fundamental reasons.

Good security practices have numerous benefits:

  • fewer work errors and better quality control.
  • fewer occasions of unplanned down time.
  • better confidence in ability to handle exceptions quickly and efficiently.
  • better understanding of business relationships, dependencies, and trust decisions.
  • better understanding of roles and responsibilities.
  • better cost controls of the products and services purchased by your organization.

As you can see, good security practices can achieve much more than audit compliance.

Is your security program achieving it’s potential?

Security Misconfiguration is the #5 risk in 2017.

The latest “OWASP Top 10” lists “Security Misconfiguration” as the #5 security risk in 2017. Does your organization review it’s security configurations? Do you validate and test them? Does your organization practice configuration management?

 

 

Being agile, it’s not that complicated.

Some of the conversations I’ve been drawn into about Agile have been nothing short of mind-numbingly overcomplicated.  The Manifesto for Agile Software Development and the Twelve Principles of Agile Software are actually quite straightforward.
The manifesto only contains 62 words (354 characters).  The principles are described with 180 words (1,081 characters).
Yet, Amazon.com currently offers 4,521 books on “agile”.
If you really feel the need to read (or promote) a book about being agile… read “Corps Business: The 30 Management Principles of the U.S. Marines”.


   According to the “Scrum Alliance: Certified Agile Leadership Program”, an Agile Leader:

  – Operates effectively amid uncertainty, complexity, and rapid change
– Is knowledgeable about Agile values, approaches, and practices
– Surfaces more creative solutions through increased self-awareness, a growth mindset, and engaging others
– Aligns and empowers teams toward delivering more customer value
– Personally integrates feedback and experiments, and adapts their ways
– Takes a collaborative continuous-improvement approach to organizational effectiveness
– Catalyzes change in others and facilitates organizational change

Um… yeah… just give me a couple Marine Privates and stand back.  I’ll take someone whose earned their Eagle, Globe, and Anchor over a certificate of attendance, any day.

Hydrologic Sensor Engineering

Many improvements in remote sensing available, but not quite ready for the Internet of Things (IoT). Data availability and data privacy aren’t big obstacles. But, for data integrity, still need solutions for issuing and managing digital signing keys for remote sensors.

Situations where JIRA doesn’t meet the needs of a project (JRA-846).

When evaluating tools like JIRA, HP ALM, or IBM Rational, it’s important evaluate project needs vs product capabilities.  Obviously the costs of getting started with JIRA are much lower than some alternatives.  But sometimes, being penny-wise can result in being pound-foolish.

For a simple “MVC” type application with a limited set of components, it’s likely JIRA’s features will be adequate. Or project needs can be met with some minor customizations and/or plugins.

However, when managing ongoing development of systems which contain many levels of hierarchical components, the JIRA limitations may present significant obstacles.  For many years, there have been open feature requests regarding support for hierarchies.  As of March 4, 2014, JIRA’s response is that it will be another 12 months before they “fit this into their roadmap”.

Jira JRA-846 Support for subcomponents

For large distributed systems, with complex dependencies, this presents a significant challenge.

While setting up a new JIRA/Atlassian environment for a solution comprised of 8 major applications, I’ve found that it is not possible to create a hierarchy of subcomponents.  Nor is it possible to establish versioning for those subcomponents.  Instead, the JIRA data model and workflows are designed for all components of a project to exist as a flat list.  And for all components to be on the same version / release cycle.

For our solution, many of the major applications start with a commercial product, incorporate multiple modules, integrate an SDK, integrate 3rd Party plugins, and finish with custom coding of multiple subcomponents.  The design pattern is to establish interface boundaries, decouple the components, and enable components to be updated independently (some people call this SOA).

Now I’m am getting a clearer picture of when it is time to consider alternatives such as HP ALM or IBM Rational.  In the past, I’ve encountered several very successful JIRA implementations.  And I’ve encountered a number of failures.

Comparing my current experience of setting up a new “systems development” project in JIRA with those past experiences, now I understand the tipping point was a matter of component complexity.  JIRA’s architecture needs to be changed such that components can be containers for other objects, and can be versioned independently.  There are elegant/simple ways to introduce a data model which supports this, it will likely require them to refactor most (if not all) of their application stack.  Given their success with smaller projects, it’s easy to understand their business decision to defer these feature requests.

JIRA continues to recommended workarounds, and several 3rd party plugins attempt to address the gap.  Unfortunately, each of these workarounds are dependent upon the products internal data model and workflows.  JIRA themselves have discontinued development of features which support one of their suggested workarounds.  And some 3rd Party plugins have stopped development, most likely due to difficulties staying in sync with internal JIRA dependencies.

It can take six months to two years to get an HP ALM or IBM Rational solution running smoothly, and there are ongoing costs of operational support and training new developers.  However, there are use cases which justify those higher costs of doing business.

It’s unfortunate my current project will have to make do with creative workarounds.  But it has provided me an opportunity to better understand how these tools compare, and where the boundaries are for considering one versus the other.

Industry Architecture – it’s a tad more complicated than Enterprise Architecture

While trying to “summarize” some of my previous work for the Service Provider industry, I realized it appears no one has coined the phrase “Industry Architecture”.

So… I’m staking my claim to the phrase now.

Think I’ll update the title on my business cards.

Here’s the mission of an Industry Architect:

Develop a new technology which gets more useful as more organizations and people use it.  To reach it’s potential, it will need so many users that it will require multiple vendors, manufacturers, developers, and large customers (such as Tier 1 Service Providers) to adopt it.  In fact it will need multiple standards bodies and regulatory agencies to get on board.

As a result of user adoptions, old companies may likely cease to exist.  New companies will emerge.  If successful it could even change behaviors on a global scale.

That’s Industry Architecture.