Bronco Webinar 800x100 1
Semiconductor Expert Forum

Posted on

When the Wrong Person Leads Cybersecurity

When the Wrong Person Leads Cybersecurity
by Matthew Rosenquist on 11-26-2018 at 9:00 am
Categories: Security
3 Comments

Succeeding at managing cybersecurity risks is tremendously difficult even for seasoned professionals. To make situations worse, poorly suited people are often chosen to lead security organizations, bringing about disastrous results. This has contributed to weaker risk postures for organizations and the rapid turnover in cybersecurity leadership.

I am unhappy to report that the industry has a pervasive problem that few want to discuss: a propensity to enlist inexperienced or unsuitable professionals to lead cybersecurity. It is time to change that caustic and enabling behavior by first recognizing the problem.

As an example, recently in the news, there was criticisms for someone appointed with the responsibility to lead the cybersecurity effort for the 2020 Olympics, but had “never used a computer”. How does someone who has never used a computer and has difficulty answering basic questions about USB drives, be tasked with building a cybersecurity program to protect the digital security, privacy, and safety for hundreds of thousands of people?

Downward Spirals
Sadly, I have seen similar situations play-out over and over again across academia, business, and government sectors. Far too often, poorly suited people are appointed such roles and it simply does not make sense. Let’s be clear, most are truly knowledgeable and accomplished in their primary field, but a transition to security is a significantly different domain. Engineering and product management executives focus mostly on static problems where there is a solution and desired end-state. Whereas in cybersecurity, we face a highly dynamic set of threat agents, people who are creative, intelligent, motivated, and dynamic, who will adapt to any solution. There is no permanent fix for cybersecurity as it is an ongoing competition to managing risks between defenders and attackers.

Human nature, overconfidence, and a lack of understanding the challenges begins to shape a counterproductive mindset. It is common for a professional from a different discipline, transplanted and put in charge of cybersecurity, to believe their prior expertise is equally applicable to the new challenges. Somehow, magically, they think they are as proficient and insightful at an adjacent domain as their previous profession. To those experienced in adversarial challenges who have seen this unfold, it is an affront to common sense. It is no surprise that such dangerous situations most often result in momentous failure.

For years, the turnover rate in cybersecurity leadership positions across the industry has been very high, with most Chief Information Security Officers (CISO) only lasting 2 to 4 years. When surveyed, CISO’s cite a lack of executive management support or insufficient budgets were the pervasive motivators. But that is only one side of the story as many CISO’s have been let go.

I have always been curious what C-suites and board had to say. When I ask company leaders about a change in cybersecurity leadership, I often hear that an outgoing CISO was ineffective, could not communicate risks well, and demanded significant budget increases every year yet the organization did not show a commensurate benefit. Events culminated when a severe incident occurred and then the C-suite or board chose to find a new security leader.

With the shortage of CISO’s in the industry, those displaced quickly find another company and continue their ‘training’. This musical-chairs routine does not serve the company or overall industry needs very well and simply transplants problems from one organization to another.

Masters of All
This mistake occurs regularly with technical personnel, probably as cybersecurity is generally characterized as a technology problem by the unacquainted. An accomplished engineer or architect is put in charge of security and now with ‘cybersecurity’ in front of their title they truly believe they are a risk expert. They are not. Being savvy in technology vulnerabilities and exploits is far different than understanding the massive breadth involved in managing risk. Most are unwilling to admit their shortsightedness in the breadth and depth of the challenges and their arrogance simply becomes a hinderance to seeking the needed help to be successful.

Ego can be such a major hindrance when the fear, of being perceived as not understanding a problem or knowing an answer, limits your actions. It is typical for a person in such a quandary to retreat back to familiar areas they know, resulting in defining the problem and solution only in the terms of technology. This ignores the behavioral, adversarial, and process aspects that are crucial to managing risk. With blinders on, they continue to push forward regardless, thus the car wreck begins.

Cybersecurity is more than just a ‘tech’ problem and will never be ‘solved’ with technology alone (two pervasive misconceptions from engineers first joining cybersecurity). They are likely doomed. I have seen this happen countless times and can spot it a mile away. It is like an automobile accident happening in slow motion with an overconfident driver continuing to push forward as metal bends and glass shatters.



Enlarged Version of Cybersecurity Domains

Part of the issue is that people, who are experts in one field, assume they understand the entire problem set in another adjacent but ambiguous field. It is not until they are in the new role, that they then experience the unforeseen challenges of a different world.

Imagine a hospital. Would you promote the engineer who developed a defibrillation tool to be an emergency room doctor? No. Although tools and technology play a crucial role in medicine, it is not the same as predicting, preventing, detecting, and responding to health risks for patients across their lifespan. The same applies in cybersecurity.

Technology is the battlefield, not the war. Understanding the terrain is important, but must be combined with a keen assessment of your opponents, and the ability to operationally maneuver in advantageous ways.

This is true in other fields as well. Aeronautical engineers aren’t promoted to fighter pilots and textbook publishers aren’t necessarily good grade school principals, so why do organizations make the mistake of a taking a software engineer or business-line product manager and expect them to be successful in leading cybersecurity?

Two Scenarios: Vastly Different Chances for Success
Now, I did say this is a recipe for failure most of the time. There are some, very rare situations, where an insightful but inexperienced person takes a cybersecurity leadership role and succeeds. It is possible. I have only seen it a handful of times and in every case that person was realistic about their knowledge and checked their ego at the door.

Guaranteed Failure:
An engineer, project manager, or business executive is put in charge of cybersecurity. They are confused or intimidated by security practitioners in their organization and respond by immediately surrounding themselves with like-minded, yet similarly security inexperienced people. They add other engineers, marketing, and legal people to their core echelon, inadvertently creating a self-reinforcing ineffective group-think team. Congratulations, an inexperienced leader has just encircled themselves with a cushion of people who don’t have the knowledge to challenge poor directives or independently deliver sustainable success. If you wonder what conversations with them are like, take a look at the Dilbert cartoon, specifically the ‘manager’ character. That is pretty close. Funny from afar, but frustrating up close.

Ineffectual organizations tend to grow fast, spend a lot of money, make hollow promises, tell a story of difficult times that are turning around, but have no real strategic plan, prioritized goals, or clearly defined scope with organizational roles and responsibilities. They seek non-existent cure-all solutions, and their long-term stratagem is to hope nothing bad happens while they battle daily issues. Even worse, the proficient security personnel, that may have been part of the team, will likely leave such a caustic environment for a better employer. That breaks my heart when I see capable people who want to make a difference, driven away. When quality employees begin jumping-ship en-masse, it is a sure warning sign.

The easiest way to detect this situation early on, is to look at their metrics, or lack thereof. If a security organization operates without the benefit of tangible metrics, it is a likely sign they have not defined or are not tracking against goals, roles, objectives, and probably aren’t measuring or tracking risk. What they are doing is responding to issues, self-marketing, rapidly growing the team, consuming significant resources, slowing down the business, and the looking for people to blame when their ineffectiveness becomes apparent. These orgs don’t last. They implode. People quickly leave and executive oversight will soon look past the whitewash to cut budgets, headcount, and eventually replace the leaders.

Potential for Success:
An engineer, project manager, or business executive is put in charge of cybersecurity. They understand they are not a security expert, so they assemble a team who has experience and talent in protecting digital assets, understanding threats, can articulate risks, and are intimate with the technology in use. They build an organization structure that is comprised of operations, engineering, and risk intelligence teams. Then listen and learn. Great leaders bring in the best people and let them excel. They quickly get clarification on the business goals and expectations from executives and customers. They then identify prioritized objectives, define a scope, derive the supporting measurable goals, identify areas in need of immediate attention, and establish the measures & metrics necessary to track progress.

Governance issues are addressed and a strategic process capability is embedded to constantly improve the organizations risk management ability to predict, prevent, detect, and respond to threats. They establish both the tactical plans necessary for immediate survival and day-to-day management, but also define a long-term directional strategy that takes into account the ever-evolving threat landscape, technology changes, and shifting expectations for security, privacy, and safety.

Proficient security workers thrive in such organizations and rarely leave. With a strong plan and capable team in place, leaders can effectively communicate and advocate across the organization. If all of these elements land in place, with the proper support, even an inexperienced security leader can have a chance at success.

Unfortunately, it rarely happens.

Failure is Expensive
Cybersecurity is difficult. It becomes exponentially more problematic when someone who lacks the necessary mentality or skills comes in and makes it profoundly worse. Cleaning up an ineffective legacy security program is painful, expensive, and time consuming. Simultaneously, a poor risk posture opens the door to more attacks and greater impacts until a capable security program is instituted.

We must understand that cybersecurity, like many other highly specialized roles, requires a depth of insight and experience to lead. I will echo Sun Tzu’s “…do what is great while it is small” and recommend putting a good leader in place the first time to build an effective and sustainable cybersecurity organization.

Let’s all break the silence and openly discuss the cycle of poor cybersecurity leadership, for everyone’s benefit.

For more insights on the challenges and required strategic deliverables, read my post Cybersecurity Fails Without Strategy.

Posted on

Making AI Silicon Smart with PVT Monitoring

Making AI Silicon Smart with PVT Monitoring
by Tom Simon on 11-26-2018 at 7:00 am
Categories: AI, IP, Moortec

PVT – depending on what field you are in those three letters may mean totally different things. In my undergraduate field of study, chemistry, PVT meant Pressure, Volume & Temperature. Many of you probably remember PV=nRT, the dreaded ideal gas law. However, anybody working in semiconductors knows that PVT stands for Process, Voltage and Temperature. Well, at least the T still stands for temperature. One out of three isn’t bad.

Chip operation is completely dependent on these three parameters. It would be hard enough to make some of the most advanced chip produced today if PVT were constant across the chip or across time. However, no such luck for chip designers, because each of these varies from chip to chip and across each chip as well. So, guard-bands, margins and binning were all created to deal with this reality.

All of the above techniques still leave a lot of performance, yield and reliability on the table. With the rapid growth of AI and the demand for dedicated silicon to address this market, the need to manage all three of P, V, T has grown too. AI chips are on leading nodes, very large and often have low power or high reliability requirements – such as ISO 26262 when used in automotive systems. Well, drawing on the chemistry reference above, wouldn’t it be nice if there was a Maxwell’s Daemon for regulating chip performance at a microscopic level?

While Maxwell’s Daemon is an imaginary inspector of molecules that controls an imaginary gate to seemingly impossibly controvert the laws of thermodynamics, there are practical solutions to monitoring and appropriately controlling fine grain circuit operation. Think of it as intelligence for artificial intelligence silicon. This is what Moortec’s PVT monitoring IP does across state of the art AI chips.

With AI chips there are often hundreds or more processing elements working in parallel, needing to be fully synchronized. Processing elements that are running too fast are wasting power. Ones that are running too slow, hold up the entire chip. Moortec PVT monitoring blocks can be dispersed throughout a design to help tune operation to ensure that the timing on all elements is similar.

Another area where PVT monitoring can help ensure reliable chip operation is to detect and compensate for aging. As chips age their performance characteristics change. PVT monitors can assess the actual performance of silicon in real time and permit the adjustment of operating conditions to maintain proper operation.

Lastly, due to the possibility of thermal runaway, PVT monitoring can monitor chip operations, and help detect a hot spot before thermal runaway can begin. The real-time element is important because joule heating is load dependent and can change rapidly and may be localized. In the worst case if adjustment is not adequate, device shutdown might be necessary. PVT monitoring allows silicon operation with the highest performance, with safeguards in place to ensure operation within safe operating range.

Moortec has IP for voltage, process and temperature sensing that are connected to create an on chip network or fabric for monitoring and managing performance. Their sophisticated PVT controller supports multiple monitor instances, statistics gathering as well as other compelling features. Moortec offer these IPs on TSMC 40nm, 28nm, 16nm, 12nm and 7nm and have a webpage dedicated to AI, among their other application areas.

Posted on

You Cruise You Lose

You Cruise You Lose
by Roger C. Lanctot on 11-25-2018 at 7:00 am
Categories: Automotive
1 Comment

General Motors has two media magnets in CEO Mary Barra and Cruise Automation founder Kyle Vogt. Barra is praised for boosting GM profitability while streamlining operations and making strategic investments. Vogt, the beneficiary of one of those investments – in his autonomous vehicle technology company – embodies GM’s aspirations for tech leadership even as he burns cash at upwards of $200M/quarter.

GM has used this one-two punch to boost its stock in the context of an inchoate melodrama pitting GM/Cruise against Waymo in the battle for autonomous vehicle market leadership. Both companies make claims about delivering commercial (driverless) autonomous vehicle services some time in 2019 and each claims to have the advantage over the other.

The Waymo vs. Cruise story plays well in the popular press but is severely misleading. There are literally dozens of organizations around the world working on perfecting autonomous vehicle technology (just ask my colleague, Angelos Lakrintis) and there may be as many as a dozen already offering commercial autonomous vehicle solutions.

Ridecell, for one, acquired Auro last year – an operator of autonomous shuttles operating in fixed environments such as university campuses. Ridecell subsequently upped its game by registering to test autonomous vehicles on roads in California.

Waymo has been testing its technology in vehicles operating in sunny California and Arizona, just like Cruise. A massive delta has opened up between Waymo and Cruise based on reported disengagements – a yawning gap that Cruise attributes to its operating primarily in San Francisco vs. Waymo’s more forgiving suburban operating environment.

The comparisons regarding strategy are more salient as Cruise is targeting urban operation of an autonomous shuttle system, while Waymo appears to be focusing on a solution capable of operating between suburban and urban environments, including highways. This is a critically important distinction between these two operators and definitely under-appreciated.

First of all, to review, Ridecell is already operating autonomous shuttles in various locations and is now seeking to expand to public roads. Navya is already operating autonomous shuttles in Las Vegas. In this context it is hard to get overly excited at the progress of either Cruise or Waymo.

The status of technological development and the progress toward market adoption is even more complicated. All indications are that Waymo has an advantage that extends beyond its far lower disengagement rate relative to Cruise.

By focusing on inter-urban applications for automated driving, Waymo has fixed on the core differentiating factor of its potential future service offering. Organizations that are focused today on delivering people or products from one location to another will tell you that the most numerous and valuable routes are those delivering people and/or products into or out of cities.

Waymo is honing in on these use case scenarios as well as those relating to moving people around suburban areas – currently poorly served by taxis and other ad hoc transportation services. It’s easy to be seduced by the challenges of automating transportation solutions in a city such as San Francisco. Sadly, the reality is that the best revenue opportunities reside elsewhere.

Cruise’s focus on San Francisco highlights the work of other AV pioneers seeking to overcome the formidable challenge of intra-city transport. The only problem with prioritizing this proposition is that the competition – primarily in the form of public transport – is fierce.

Waymo’s advantage lies not only in its massive portfolio of miles driven and miles simulated. The company also has a fundamental business model and strategy advantage that Cruise is ill-equipped to overcome.

But this is why this story is so compelling, like the tortoise and hare parable that preceded it. Each operator has its advantages and each has a compelling story to tell.

Cruise appears to be the hare of this tale, as a startup and even with GM’s and SoftBank’s and Honda’s subsequent investments has doubled-down on its hare status. Oddly, GM has so far kept Cruise walled off from its own autonomous vehicle development activities manifest in Super Cruise – an enhanced cruise control system which integrates advanced vehicle positioning technology and driver monitoring to allow drivers of certain Cadillacs to take their hands off the wheel under appropriate circumstances.

My money is on the tortoise, Waymo. Waymo is boring. But boring is a virtue in this case. The company is publicity averse – certainly relative to Cruise – and its strategy appears to be relatively transparent. As a former journalist it is difficult for me to praise a company that seems to be avoiding the press – but it is an understandable affliction in the autonomous vehicle industry.

In fact, GM’s inclination to communicate Cruise-related developments to the press only makes its organization more suspicious. Is Cruise making legitimate progress or is the entire effort nothing more than a stock manipulation? I leave it to you, dear reader, to correlate Cruise announcements and press “reveals” to stock price movements.

Cruise may be on to something by focusing on urban AV operation, but even successful driverless operation of automated vehicles will require substantial populations of expensive human support personnel for monitoring, servicing, cleaning and retrieving autonomous vehicles. Cruise’s urban-centric battle plan faces serious unacknowledged headwinds.

Waymo, on the other hand, is mastering the art of operating in a range of environments, urban and otherwise. Both companies, though, will have to contend with the regional nature of AV operation and the challenges of variable weather.

The oddest thing of all, though, is the fact that Cruise and GM choose to compete with one arm tied behind their back. GM is the largest Mobileye customer on the planet. This means that GM has the most cars with built-in forward facing cameras connected to telecommunications control devices – called TCUs.

Like Tesla, GM could tune its forward facing cameras to gather data in support of automated driving development. GM does not do that. Where forward facing cameras are available on GM vehicles the company is applying them for recreational or simple safety purposes.

GM lets its customers use the forward facing cameras in Corvettes to record scenic drives or their latest visit to the race track. Forward facing cameras on other GM vehicles are used for surround view applications.

Like its groundbreaking OnStar vehicle connectivity technology, GM is under-leveraging its camera-based investments. OnStar might have been a crowdsourced traffic solution like Waze long before the existence of Waze, but the company chose to avoid the cost of wireless data collection implicated in that use case.

Like Tesla, GM could be collecting vehicle data in support of autonomous vehicle development activities. But the company is still obsessed with cost avoidance (regarding wireless data) – and privacy – which is beginning to look like avoiding value creation.

If GM fails to keep pace with or surpass Waymo it is because the company willfully failed to leverage its technological advantage inherent in its management of the largest connected fleet in the U.S. and the broadest deployment of connected forward facing cameras. It makes one wonder whether the media magnates at GM are more interested in the limelight and the stock price than transforming transportation.

Roger C. Lanctot is Director, Automotive Connected Mobility in the Global Automotive Practice at Strategy Analytics. More details about Strategy Analytics can be found here: https://www.strategyanalytics.com/access-services/automotive

Posted on

You Can’t Get There From Here

You Can’t Get There From Here
by Bill Montgomery on 11-22-2018 at 12:00 pm
Categories: IoT, Security
1 Comment

No doubt many who read this article have heard the expression “You can’t get there from here…” It’s most often attributed to New Englanders – primarily residents of Maine – to describe a route to a destination that is so circuitous and complex that one needn’t bother embarking on the journey.

In the context of the business world, the expression takes on different meaning. It defines a situation where the leaders of a business can see what needs to be done, but can’t in any way define an easy, clear, financially-viable path to achieve what’s required. For example, in the late 1990’s when one of the largest, most successful companies serving the telecom sector – Northern Telecom (aka Nortel) – realized that the TCP/IP Protocol was viable for business networking applications, and that young upstarts like Cisco were aggressively staking their claim to this space, it was too late. Nortel’s entire business was based on selling clunky digital switches and networks, and it couldn’t abandon its core offerings and income streams to embrace the change that its executive team knew was needed. It tried, by acquiring Cisco competitor, Bay Networks, but reality quickly set in. The market finished the Nortel story by figuratively stating, “You can’t get there from here.”

I believe that expression captures the current state of IoT, and while it’s not exactly comforting, it’s nice to know that I’m not alone in my view. Renowned security expert and best-selling author, Bruce Schneier, appears to be on the same page.

Click Here to Kill EverybodyI just finished reading Mr. Schneier’s new book, Click Here to Kill Everybody, and I thoroughly enjoyed it. Though I suppose enjoyed it is not exactly accurate. It’s more like I enjoyed Bruce’s writing style which makes for easy reading, and I found myself fully aligned with his insightful views on the incredible risks that our world is facing due to the massive vulnerabilities inherent in the Internet. And worse, those vulnerabilities and the danger that they create are increasing at a staggering rate due to the widespread deployment of non-secure IoT devices.

And unfortunately, I also agree with Bruce’s conclusion that nothing is going to happen in the near term to fix our broken connected world. He writes, “As a society, we haven’t even agreed on any of the big ideas. We understand the symptoms of insecurity better than the actual problems, which makes it hard do discuss solutions. We can’t figure out what the policies should be, because we don’t know where we want to go. Even worse, we’re not having any of those big conversations…Internet+ security isn’t an issue that most policy makers are concerned about. It’s not debated in the media. It’s not a campaign issue in any country I can think of…”

Put another way, the Internet is so pervasive, so unmanageable and IoT deployment is so out of control, that rendering all of it secure today is….well…“You can’t get there from here.”

Mr. Schneier doesn’t only paint a picture of gloom and doom. He has some practical suggestions on how to solve our current dangerous dilemma, and he remains confident that in the long term the security problem will be solved. I agree, and while technological advancements, business leaders and governments will surely be involved in crafting this long-term solution, I believe that there are things we can do in the near term that can immediately close big IoT security holes for the greater good.

Start with the Things
It all starts with the things or devices. The State of California is the first US government to recognize this and to that end, recently passed a cybersecurity law that states that any manufacturer of a device that connects “directly or indirectly” to the Internet must equip it with “reasonable” security features designed to prevent unauthorized access, modification, or information disclosure. If it can be accessed outside a local area network with a password, it needs to either come with a unique password for each device, or force users to set their own password the first time they connect. That means no more generic default credentials for a hacker to discover. The law comes into effect on January 1st, 2020, giving manufacturers plenty of time to comply.

And while this law appears to be a positive step, security blogger Robert Graham has slammed the bill as bad, stating it is “based on a superficial understanding of cybersecurity/hacking that will do little to improve security, while doing a lot to impose costs and harm innovation.”

If you read Mr. Graham’s entire blog (accessed via the above link), he makes some very good points. One that resonates with me is the complexity and vulnerability inherent in current approaches to authentication. Graham notes that “A typical IoT device has one system for creating accounts on the web management interface, a wholly separate authentication system for services…” He goes on to write, “That was the problem with devices infected by Mirai [author’s note: the IoT attack that almost brought down the Internet]. The description that these were hardcoded passwords is only a superficial understanding of the problem. The real problem was that there were different authentication systems in the web interface and in other services like Telnet.”

The authentication issue is also addressed in Click Here to Kill Anybody.Mr. Schneier concludes, “as bad as software vulnerabilities are, the most common way hackers break into networks is by abusing the authentication process. They steal passwords, set up man-in-the-middle attacks to piggyback on legitimate log-ins, or masquerade as authorized users.” His conclusion: “Authentication is getting harder and credential stealing is getting easier.”

A New World Approach to Authentication
I agree with Bruce Schneier. Authentication – the process of identifying a person or device – is getting harder. And given that the IoT world continues to rely on broken vulnerable protocols and technologies, it’s no wonder. What’s needed is an innovative, standards-based new approach to authentication that can completely eliminate the risks posed by stolen credentials.

Now, before you continue reading this article (and thanks for getting this far into it), I need to post a disclaimer.

In the many years that I have been writing IT Security related articles, I’ve made a conscious effort to avoid promoting my company, in favour of publishing articles that I hope bring attention to the serious IoT security issues our world faces, and to do so in an informative, perhaps entertaining manner.

However, from this point forward in this article, I’m deviating from my personal publishing policy, because I think what I’m about to write is important as it introduces a dramatically more effective, secure and economical way of handling IoT authentication (and key management).

So, if you’re not a fan of the “advertorial” writing style, I suggest you stop here and we’ll catch up the next time I post a neutrally-written article. But if you’re curious, and want to learn more about how our technology is being deployed by others to protect their IoT services, solutions and products, please keep reading.

VIBE is an acronym for Verifiable Identity-Based Encryption. VIBE is patented technology that improves upon the market-proven IBE standard in 15 different ways, most notably by adding authentication at the application layer, and eliminating the need to protect the public parameters. The VIBE key management and authentication schema can be easily embedded in others IoT products, services or solutions.

VIBE’s “coming out” party is at the NIST’s Feb 2019 Global City Teams Challenge event as part of a Government of Singapore initiative called Project GRACE. GRACE (Graceful Remediation with Authenticated Certificateless Encryption) implements a security architecture using an advanced form of pairing-based cryptography called Verifiable Identity-based Encryption (VIBE) to provide simple, scalable and secure key management for Cloud services, the IoT and the Critical Information Infrastructure (CII) which are otherwise vulnerable to existing and new cyber-physical attacks.

Project GRACE implements an alternative set of cipher suites, containing VIBE in TLS 1.2, and maintaining forward compatibility. This standards-based approach ensures a smooth transition to the new scheme with minimal updates to the existing ecosystem of web servers and web browsers. Most importantly, the security gaps in the TLS layer are filled in the process. TLS with VIBE embedded is certifiable to ISO 27001-2013.

TLS with VIBE accommodates deployments on a very large scale – the Internet scale – as it eliminates the complexity of using PKI-based SSL/TLS certificates in web servers/browsers, and does so economically.[

Once configured the Control Server can run offline from the Trust Centre (TC), and any device can be authorized to communicate with another without key management intervention.

When the system is setup, the TC can be taken offline, and easily and temporarily reinstated when there is a requirement to reconfigure existing devices and/or add new devices.

As our Asian and EU partners have discovered, VIBE-inside products, services and solutions solve the authentication issue permanently.

If you’re interested in learning more about VIBE, please send me a note and I’ll pass along a copy of our FAQ. Also, as the work required to embed VIBE in our Partner’s HSMs and Chips is near completion, we are welcoming dialogue with companies interested in participating in a IoT Pilot Projects.

#AuthenticateEverything

Posted on

Dover Microsystems Spins New Approach to Security

Dover Microsystems Spins New Approach to Security
by Bernard Murphy on 11-22-2018 at 7:00 am
Categories: Arm, IoT, RISC-V, Security

One of the companies I met at ARM TechCon was Dover Microsystems who offer a product in embedded security. You might ask why we need yet another security solution. Surely we’re overloaded with security options from ARM and many others in the forms of TEEs, secure boots, secure enclaves and so on? Why do we need more? Because defending against security breaches is a never-ending battle; no-one is ever going to have the ultimate answer. This is particularly true in software, which is only guarded in the most secure of these systems to the extent that software designers comprehensively consider potential attacks and correctly use whatever memory protection strategies are provided. Given the complexity of modern software stacks, that is not a trivial task.

So how are you going to defend against vulnerabilities you don’t even know exist – the unknown unknowns? Dover have come up with an interesting idea that I like to think of as rather like runtime assertion-based verification (ABV). Think about why we use ABV in hardware design verification. We can’t anticipate everything that might possibly go wrong in a complex system, but we do know that there are certain statements we can make about behavior that should always be true or conversely always false. We have a language in which we can write these assertions (most commonly SVA) enabling us to write our own arbitrarily complex checks. When an assertion triggers in simulation, we trace back in debug and typically find some unexpected combination of conditions we never considered. Even though we hadn’t thought of it, the ABV approach caught it anyway.

I’ve long been a believer that ABV in some form could have value beyond design verification, catching problems at runtime. This could trap potential error conditions, for immediate defensive response and for later diagnosis, leading to software revs to defend against whatever unusual state triggered the problem.

From my perspective, Dover takes an approach along these lines, but instead of assertions being embedded in the mission hardware, they run in a separate IP they call a “policy enforcer” and Dover uses “rules” rather than “assertions” to describe what they check. A collection of rules to check for a class of attacks they call a “micropolicy”. Also they’re not looking at microarchitecture behavior; they’re watching the processor instruction trace and attempted writes to memory, (along with some additional data) which makes sense since they are looking at software-based attacks. They do this in a dedicated processor, sitting to the side of the main processor, so performance impact is limited and attacks on the main processor don’t affect this processor. Nothing is immune from attacks of course but separating this function should make attacks on this monitor more difficult.

In my assertion analogy, the assertions are bit more complex than just direct checks on instructions and addresses. You might build a state table to track where you are in significant aspects of operation flow, also you may choose to label (color) data in different regions. Dover call this information built for and used by the policies “metadata”, which they store in a secured region of the main memory. So when a rule is checking the validity of an operation (say a store), it can check not only the current instruction and target address, but also the metadata. Not too different from the fancy assertions IP verification experts build for protocol checking.

When a policy is violated, the current instruction will not be allowed to complete, and an exception is triggered in the main processor. How this is handled is then up to the kernel/OS. In a package delivery drone for example, an exception might cause the drone to disable network connections, switch into safe mode, load a home GPS location from an encrypted store and fly there.

Dover includes a base set of four micropolicies with product. The read-write-execute (RWX) micropolicy is designed to label regions or even words in memory as readable, writable and/or executable so that operations in violation of this labelling will be caught. The Heap micropolicy is designed is designed particularly to catch buffer-overflow exploits. A pointer to a buffer and the buffer itself (created on a malloc) are colored the same. Attempting to write beyond the upper boundary of the malloc, into a differently-colored region, will trigger a violation. In the Stack micropolicy, stack-smashing attacks which attempt to modify the return address through (compile-time sized) buffer overwrites are prevented. This is conceptually similar to the heap approach but must preserve the integrity of the whole stack.

The fourth base micropolicy is called CFI, for control flow integrity, and is designed to trap code-reuse attacks. These are a variant on return-oriented programming (ROP), where instead of trying to return to an injected malware routine, the code returns to a libc function, such as “system” which can then execute externally-provided malware. The CFI micropolicy profiles locations that contain instructions rather than data and targets/destinations of jumps. This profile cannot be altered during runtime. If a non-tagged location attempts a jump, or a jump is attempted outside the profiled set, the policy will trigger an error.

Dover’s CoreGuard IP integrates with RISC architectures (ARM and RISC-V). The technology originated as part of the DARPA CRASH program in 2010, was incubated by Draper in 2015, and was spun out through Dover as a commercial entity in 2017. The company has now grown to over 20 people and has closed an initial $6 million round of seed funding. Even more impressive, they are working with NXP towards embedding their solution in NXP controllers. You can learn more about the company HERE.

Posted on

Technology Transformation for 2019

Technology Transformation for 2019
by Matthew Rosenquist on 11-21-2018 at 12:00 pm
Categories: Security

Digital technology continues to connect and enrich the lives of people all over the globe and is transforming the tools of everyday life, but there are risks accompanying the tremendous benefits. Entire markets are committed and reliant on digital tools. The entertainment, communications, socialization, and many others sectors are heavily intertwined with digital services and devices that society is readily consuming and embracing. More importantly, the normal downstream model for information has transformed into a bi-directional channel as individuals now represent a vast source of data, both in content as well as telemetry. These and many other factors align to accelerate our adoption and mold our expectations of how technology can make a better world.

This year’s Activate Tech & Media’s Outlook 2019 presentation provides a tremendous depth of insights in their slide deck (153 slides) with a great amount of supporting data. It highlights many of the growth sectors and emerging use-cases that will have profound impacts on our daily lives.

Transforming Tech Intelligence
We are moving from the first epoch of digitally connecting people, to the second epoch of making intelligent decisions through technology. Artificial Intelligence research is advancing and with it the infrastructure necessary to make it scalable across a multitude of applications. Solutions are just beginning to emerge and yet showing great promise to make sense and use the massive amounts of data being generated.

Overall, devices and services continue to evolve with more awareness and functionality. We are in the ramp of adding ‘smart’ to everything. Smart: cars, cities, homes, currency, cameras, social media, advertising, online-commerce, manufacturing, logistics, education, entertainment, government, weapons, etc. It will be the buzzword for 2019-2020.

Such transformation opens the door where tools can begin to anticipate and interweave with how people want to be helped. Better interaction, more services, and tailored use-cases will all fuel a richer experience and foster a deeper embrace into our lives. Technology will be indispensable.

Risks and Opportunities
Reliance in our everyday activities means we have the luxury of forgetting how to accomplish menial tasks. Who needs to remember phone numbers, read a map, operate a car, or know how to use a complex remote control. Soon, our technology will listen, guide, watch, autonomously operate, and anticipate our needs. Life will seem easier, but there will be exceptions.

All these smart use-cases will require massive data collection, aggregation, and processing which will drive a new computing infrastructure market. Such reliance, intimate knowledge, and automation will also create new risks.

The more we value and rely on something, the more indebted we are when it fails. We must never forget that technology is just a tool. It can be used for good or for malice. There will be threats, drawn to such value and opportunity, that will exploit our dependence and misuse these tools for their gain and to our detriment. At the point people are helpless without their intelligent devices, they become easy victims for attackers. As we have seen with data breaches over the past several years, when people are victimized, their outlook changes.

In this journey of innovation and usage, public sentiment is also changing across many different domains. The desire for Security, Privacy, and Safety (the hallmarks of Cybersecurity) continues to increase but may initially be in direct conflict for our desire to rapidly embrace new innovations. This creates tension. We all want new tech toys (it is okay to admit it)! Innovation can drive prosperity and more enjoyment in our lives. But there are trade offs. Having a device listen, record and analyze every word you say in your bedroom may be convenient in turning on the lights when you ask, but it may also inadvertently share all the personal activities going-on without your knowledge. A smart car effortlessly transporting you to work while you nap or surf the internet sounds downright dreamy but what if that same car is overtaken by a malicious attacker who wants to play out their Dukes of Hazzard fantasies. Not so much fun to think about.

In the end, we all want to embrace the wonderful benefits of new technology, but will demand the right levels of security, privacy, and safety.

Trust in Technology
Unfortunately, trust in digital technology is only now becoming truly important. In the past, if our primary computing device (PC or phone) crashed, we breathed a small curse, rebooted and went on our way. We might have a dropped call or lost part of a work document, but not much more harm than that. That is all changing.

In the future, we will heavily rely on technology for transportation, healthcare, and critical infrastructure services. That autonomous car we expect not to crash, the implanted pacemaker or defibrillator we expect to keep us alive, or the clean water and electricity we expect to flow unhindered to our homes may be at risk of failure, causing unacceptable impacts. We want tech, but very soon people will realize they also need security, privacy, and safety to go along with it.

But how will that work? We don’t typically think of trust in terms of high granularity. We naturally generalize for such abstract thoughts. We don’t contemplate how trustworthy a tire, bumper, or airbag is, as those are too piecemeal, rather we trust the manufacturer of the car to do what is right for all the components that make up the vehicle we purchase. We want the final product, tied to a brand, to be trustworthy. For those companies that we trust, we tend to believe, whether correct or not, in all their products and services. This reinforces tremendous loyalty. The reverse is true as well. One misstep can become a reputational blight affecting sentiment across all a company’s offerings.

The saying “We earn trust in drips and lose it in buckets” perfectly exemplifies the necessary level of commitment.

Trust may become the new differentiator for companies that can deliver secure and safe products in a timely fashion. Those who are not trustworthy may quickly fall out of favor with consumers. Privacy is the first in many problems. Consumers, government regulators, and businesses are struggling to find a balance that must be struck between gathering data necessary for better experiences, but not too much that it becomes a detriment to the user. A difficult conundrum to overcome. Security and safety aspects will follow, where the potential risks grow even higher. The challenges are great, but so will the rewards for all those who succeed. I believe those companies which master these disciplines will earn long-term loyalty from their customers and enjoy a premium for their products.

2019 might be the first year where we witness this delineation as consumers may gravitate to more responsible companies and begin to shun those who have misplaced their trust. The big story for next year may in fact be how purchasing decisions for technology are changing, thus driving greater commitment to making products and services more security, private, and safe.

#cybersecurity #informationsecurity #technology #risk #LinkedInTopVoices

Interested in more insights, rants, industry news and experiences? Follow me on Steemitand LinkedIn for insights and what is going on in cybersecurity.

Posted on

Design Compiler – Next Generation

Design Compiler – Next Generation
by Alex Tan on 11-20-2018 at 12:00 pm
Categories: EDA, Synopsys

Back in 1986, Synopsys started out with a synthesis product by name of SOCRATES, which stands for Synthesis andOptimization ofCombinatorial logic usingRule-basedAndTechnology independentExpertSystem. It is fair to say that not many designers know that was the birth name of what eventually turns out to be a very successful synthesis tool –Design Compiler. Over the last three decades, it has evolved to keep pace with the push and pull of Moore’s Law, advancements in process technologies, compute architecture shift and better software algorithms. Let’s replay how it has evolved over time.

Drivers to the Evolution
The first generation of Design Compiler (DC) took Boolean equations, optimized and minimized them and generated the combinatorial logic. Over time it has been revamped to handle more features such complex HDL constructs, pre-optimized building blocks (DesignWare IP), automatic DFT test-insertion and power related clock-gating among others. Its compile step also had gradually evolved from having only few options such as high, medium or low effort –to be more granular, as it accommodated increased designers awareness in optimizing more complex and higher performance logic. This includes the options to do compile_ultraand incremental compiles.
From methodology standpoint, DC interaction with the adjoining and downstream tools has been shaped by both the process-technology related geometrical scaling drive and satisfying designers automation needs. For example the use of wire load model was considered the norm during micrometer process node era. Designers who wished to push timing optimization further applied more area-centric, custom wire load models.

As wire scaling did not track well with device scaling in subsequent nanometer processes (as shown in figure 1), the lagging interconnect performance had disrupted the overall timing optimization results. TLU+ based RC modeling was then introduced to provide more accurate early wire estimation during synthesis and was embedded as part of DC-T or DC-Topographical.

While designers applied frequent synthesis cost-factor rebalancing to achieve an optimal QoR (Quality of Results), the slower interconnect had shifted top critical paths characteristic from gate dominant to more interconnect dominant, and caused a disconnect in assessing potential hot-spots (congested areas) in the design. This resulted in aggressive efforts made by the place and route tools in attempting to complete net connectivity with the available wire resources, and creating either routing congestion or scenic routes in the process. In order to account for such event, DC was once again enhanced to be ‘physically aware’ –DC-G or Design Compiler Graphical was rolled-out in 2011 to provide congestion prediction that was aligned with ICC place and route tool. Furthermore, deep advanced nodes, such as 10nm, 7nm and below, have also imposed the necessity of having accurate pre-route resistance estimation in synthesis step. DC-G was upgraded to handle such advanced nodes effects such as layer-aware optimization and via ladder.

The Next Generation Synthesis
Early this month Synopsys released Design Compiler NXT, a new addition to the Design Compiler family of synthesis products. It addresses customer demand for a greater throughput and improved PPA (power, performance and area) as well as a tight correlation to physical implementation tools. It delivers 2X faster runtime, 5% better QoR for dynamic power, and a new cloud ready distributed processing engine.

“Design Compiler NXT built on Design Compiler Graphical leadership position with innovation enabling improved quality of results and designer productivity. Technology Innovations include fast and impactful optimization engines, cloud-ready distributed synthesis, more accurate RC estimation and new capabilities to support 5 nanometers and below,” stated Dr. Michael Jackson, Synopsys VP of Marketing and Business Development.

According to Abhijeet Chakraborty, Synopsys Group Director of R&D Design Group, Design Compiler NXT incorporates high-efficiency engines yielding half the runtime for compile and optimization operations. Design Compiler NXT distributed synthesis capabilities enables each distributed machine to optimize the design with full physical and timing contexts, which yields faster synthesis runtimes without sacrificing QoR.

“Design Compiler Graphical has been the trusted synthesis tool for our designs for many years and a key enabler to the development of our advanced SoCs and MCUs,” said Tatsuji Kagatani, Vice President, Shared R&D Division 2, Broad-based Solution Business Unit, at Renesas Electronics Corporation. “We are collaborating with Synopsys on the latest synthesis technologies in Design Compiler NXT and are looking forward to deploying them on our designs to help meet our ever-increasing pressure of time-to-market and higher QoR.”

Common Library, Models and Advanced Nodes Support
Design Compiler NXT also provides users benefit through a new support to common physical libraries (common library and block abstract models) with IC Compiler II. Often times, library updates introduced during the ongoing project development may introduce library inconsistencies between synthesis, place-and-route, and physically-aware signoff-driven ECO. It also continues to support Milkyway for full backwards compatibility, a plug-and-play, user interface and script compatible with existing Design Compiler Graphical. This enables a seamless transition for users.

New power driven mapping and structuring techniques, the addition of concurrent clock and data (CCD) optimizations deliver enhanced QoR. It has been redesigned to meet modeling needs of advanced process nodes, improved interconnect modeling, net topology and local density analysis engines that delivered tight correlation to IC Compiler II.

In summary, Design Compiler has been the industry leader for over 30 years and has delivered synthesis innovation in the area of test, power, data-path and physical synthesis. With this new addition once again Synopsys is raising the bar in evolving their RTL synthesis to enable SoC designs to target many emerging applications.

For more details on Design Compiler NXT, please check HERE

Posted on

Webinar: Tanner and ClioSoft Integration

Webinar: Tanner and ClioSoft Integration
by Alex Tan on 11-20-2018 at 7:00 am
Categories: Cliosoft, EDA

A fusion of digital and analog IC circuits, mixed signal ICs are key components to many applications including IoTs, automotive, communications and consumer electronics –acting as enabler to bidirectional conversion of signals between analog domain derived from various audio, temperature and visual sensors to digital domain of the embedded processing units.

Handoff, DM and integrated SOS7-Tanner benefits
Mixed signal designers typically deal with shorter design cycles as their design will either be an IP of a large SoC or as a stand-alone IC product. In both scenarios, team collaboration and robust handoff mechanisms are needed to ensure a clean integration downstream.

As part of Mentor, a Siemens Business, Tanner EDA provides a list of design, layout and verification portfolio for analog and mixed signal (AMS) ICs, Micro-ElectroMechanical Systems (MEMS), and IoT designs for 28nm and above. As shown in figure 1, the environment consists of schematic and layout capture,
place and route, verification and chip assembly tools –segregated to serve analog, digital or mixed signals centric design.

Integrated into the Tanner design environment is ClioSoft’s SOS7 design management solution that enables local or multi-site design teams to collaborate efficiently on all types of complex SoCs – analog, digital, RF and mixed-signal – from concept-to-GDSII. The three areas DM could help are as follows:

  • Improving team efficiency such as access, revision, reuse and release control management. For example, in tracking release versions of an IP, handing-off completed schematic to the layout team for further implementation.
  • Automatic, secure and optimal real-time data synchronization across sites and compute resources. For example, design data handoff or sharing to multi-sites can be done automatically without the use of ftp, rsync, cron jobs or other insecure means.
  • Design progress monitoring through milestones audit and tracking of any open issues or completed tasks. For example, tracking on which blocks are completed and how many layouts are still pending, all can be done easily.

In order to demonstrate how tightly integrated Cliosoft SOS7 with Tanner design flow, a design involving ADC and DAC components are used. As shown in figure 2, the design data are captured in two ways: for the analog part, DAC, the schematic and layout is captured with SEDIT and LEDIT; while for the digital part, ADC control, a synthesis is involved and followed by layout generation.

Each process refers to its specific libraries (PDK or standard cells) and includes the generation of many views such as schematic, layout, pre- and post-layout netlists. Once the post-layout design verified or simulated, more views are produced such as simulation reports, measurement outputs and output data. In case of SoC design, some of these may need to be propagated further for the validation of overall system.

Without the use of DM, the design database will be a convoluted collection of directories usually in open access (OA), each consisted of many revisions of views and get replicated across into each designer’s local area to track updates –cluttering work area. With SOS7, the design database is captured in common repository along with multiple submitted revisions reducing the overall design footprint. Multi-site teams will be able to streamline design change updates and handoffs. For example a secure reservation of schematic to be worked on can be made, preventing concurrent edits. After each change, auto synchronization across other sites would be made by SOS7 cache server. These help more effective collaboration and also design data management. SOS7 also facilitates IP cataloging, capturing pertinent documentation and propagate any fixes and release to the users connected to the SOS7 Design Collaboration platform. Figure 2 (bottom part) illustrates the comparison before and after SOS7 deployment on the sample case design.

Driving ClioSoft DM in Tanner Environment
ClioSoft SOS7 GUI is invocable from within Tanner tools GUI such as S-EDIT and L-EDIT. As a design cockpit SOS7 GUI provides designers with full visibility of the state of design database such as who is editing which revision of the schematic, when a particular block is done and released, etc.

To enhance team collaboration, some steps such as tagging, labeling and snapshot are recommended during each sub process completion. As seen in figure 4, the use of tagging such as “Design Done”, “Layout Done”, “Design Verified” can be applied to signify milestone completion and inform subsequent users for the state of the database views. Similarly for snapshot as a way to capture all states up to a point (to permit undoing of work if needed).
As part of good design management practices, tracking design collaterals should cover all design related views (including binary format data files), libraries and technology files, runset and documentation. In addition, for verification or simulation related process only limit capture to run summary, logfiles, all used inputs (such as RTL) and testbenches. The remaining large actual simulation and DRC/LVS results as well as intermediate cell views should not be tracked. This will reduce overall project database footprint.

To recap, designers need an effective way to manage their project during the design phase. The integration of ClioSoft’s SOS7 Design Collaboration platform into Tanners IC Design flow allows designers to be more productive. This allows them to focus on their design instead of doing the design data management tasks as well as to facilitate early error findings and fixes –avoiding costly re-design iterations.

For more details on ClioSoft SOS7 DM check HERE and Webinar HERE.

Also Read

The Changing Face of IP Management

Data Management for SoCs – Not Optional Anymore

Managing Your Ballooning Network Storage

Posted on

Using IP in a SoC Compliant with ISO 26262

Using IP in a SoC Compliant with ISO 26262
by Daniel Payne on 11-19-2018 at 12:00 pm
Categories: Automotive, EDA, Perforce

The automotive segment is being well served by semiconductor suppliers of all sizes because of the unit volumes, and the constant push to automate more of the driving decisions to silicon and software can raise lots of questions about safety, reliability and trust. Fortunately the ISO standards body has already put in place a functional safety compliance specification known as ISO 26262, so engineers working at automotive companies have a clear idea how to document their processes to ensure that you and I as consumers are going to be safe while driving the old fashioned way with our hands on the wheel, or more towards the goal of autonomous driving which will be hands-free. Semiconductor designers can use dozens to hundreds of IP blocks in their automotive chips, so one challenge is how to be compliant with iSO 26262 while managing so many blocks.

Design companies have teams with various Functional Safety (FuSa) roles, like:

  • Functional Safety Manger (FSM) – creates a series of surveys
  • Design Engineers – uses the surveys and completes a response for each IP being used

By the end of a project the FSM has read all of the survey responses and can decide if the automotive system meets functional safety readiness or not. Methodicsis an EDA company offering their Percipienttool for IP Life Cycle Management (IPLM), and the good news is that using Percipient will help both the FSM and design engineers document and manage their ISO 26262 process.

Change is constant, so what happens if one of your semiconductor IP blocks has been updated since it’s last release? Well, with a tool like Percipient you’ll be notified that a new IP version is available, then make the decision to either keep the old one or go with the new one, all while having an audit trail of the decision, no more manual tracking because it’s a built-in feature. Even if your IP is hierarchical and has dependencies, you will always be in the loop if some lower-level IP block has changed and then decide how that change affects your compliance status. Using a design flow with Percipient lets your team manage compliance with little engineering effort while keeping the context and version awareness.

You can now achieve IP reuse by using an approach which separates the IP hierarchy and dependencies from the IP data, because Percipient is maintaining the usage and dependencies outside of the IP itself. This methodology then provides a scalable workflow while re-using IP blocks.

I introduced the concept of an FSM creating surveys based on FuSa needs, and you can have surveys used at each level of the SoC design hierarchy while re-using soft IP, hard IP, external IP. Collections of surveys to cover a specific use case are called Survey Lists. Soft IP and Hard IP can each have their own surveys and FuSa requirements:

In your team the FSM or IP owners have the flexibility to attach a specific survey to an IP. Like the above example, your team could decide that all Soft IPs should have Survey 1 attached, while all Hard IPs should have Survey 3 attached.

Even at the SoC level you will have a survey list attached, so that when you want to look at a particular survey it will filter to show only what you requested and is relevant in that context:

If FuSa compliance was not a requirement, then at the SoC level you would see none of the surveys and their results.

Let’s say that in the middle of your design project you decide to swap out the Bluetooth sub-system from one vendor to another vendor. As your team is using Percipient that tool automatically loads the surveys and results from the IPs in the new Bluetooth sub-system, while the designers keep going along their daily tasks with little impact. Version control in Percipient shows the complete history of making changes to the hierarchy, and so you can see compliance results over time. Change is constant, but your engineers aren’t paying any penalties when it comes to compliance.

Each survey result is attached to an IP block and at a specific time, so when you create or accept a new version of an IP then you get to decide if the survey results stay the same as before or are now changing. If the IP is changing enough, then it calls for a retake of the survey. With Percipient you’re going to see a traceable history of changes on survey results for each IP, while not causing extra work for designers.

Compliance reporting can be complex because there are four levels to ASIL A-D, which in turn will affect who will create the surveys and look at the reported responses. Using an IPLM software package is the way to go, because it can handle all of the permissions and restrictions tied to the different ASIL levels.

Summary
Automotive design is a growing opportunity for electronics companies and the challenges of being ISO 26262 compliant can be met more rapildy by using the appropriate software tools from vendors like Methodics. The Percipient tool is an IPLM approach that will help your team meet ISO 26262 compliance.

Read the complete White Paper online.

Related Blogs