Start at the Prologue and First Chapter here
Aleksandr Isayevich Shukov was following familiar corridors on his way to the monthly meeting of the Joint Cyber Strike Council. He was also following the Director of the Federal Security Service, walking a step behind his boss, as was appropriate. Although Shukov was the manager of all FSS cyber activities within the scope of the JCSC’s mandate, his position was based merely on ability, not political connections. If the meeting went well, perhaps the Director might reward him by engaging in conversation as they left the meeting.
Unlike most such inter-agency gatherings, the JCSC meetings were not meaningless bureaucratic exercises, valued mostly by their participants as opportunities to assess each others influence and weaknesses. Last year, the president of the Russian Federation had assigned the highest priority to the work of the JCSC. The minutes of each meeting were sent immediately to his office, skipping the usual courtesy of permitting the chief of staff of each agency director to review and correct them lest anything reflect unfavorably upon that director.
All of which put great pressure on those, like Shukov, who sat at the right hand of their directors and would be responsible for answering any question that director wished to dodge, which was to say all of the difficult ones. Woe to anyone like Shukov if they were under-prepared, allowed an impression to be formed that his agency was behind plan, or, worst of all, said anything that might make his Director look bad.
Shukov’s job was high pressure, to be sure. But it was also meaningful, and the Russian government was still filled with sinecure positions that were secure and paid well but contributed nothing, just like its predecessor, the Soviet Union. That might be fine for some, but Shukov was ambitious. He wished to advance, but lacked the political connections to do so. He would need to gain attention through real achievement. But to say that his role was meaningful in a good or a bad way was an interesting question he had never been able to resolve. Likely enough he never would.
In principle, the concept of cyber war could be seen as a positive advancement in the age-old art of war. With a few keystrokes, a well-prepared attack could darken a city, or even an entire nation, robbing it of much of the ability to respond to a physical attack. Through such means, a small nation might be overrun in a matter of hours with almost no casualties. Certainly, that was a more humane way to acquire territory or punish an enemy than softening up targets with thousands of tons of bombs before putting your own troops at risk.
And also, much more economical. To overcome the enemy in cyber war, a nation needed brains, not dollars. The Russians might not have the money the Americans did, but they had always excelled in math and sciences. Not to mention chess.
Still, cyber weapons could be more lethal than traditional arms. In the first and second World Wars, the carnage was horrifying, yet only a fraction of the population of any of the combatants were killed or wounded. Even in the Soviet Union, with its twenty million casualties, the great majority of the people survived. Sometimes hungry, yes, and miserable, certainly. But alive.
Consider, then, the consequences of taking down an enemy’s power grid and keeping it off-line for several weeks in the middle of winter – especially a Russian winter. Most of the population would die of exposure, thirst or hunger. Everything ran on or was controlled by devices reliant on electricity – the pumps that moved petrol into the trucks and trains that transported food, the computers that controlled the delivery of water and the removal of sewage, even the heating system of every home. Take away a developed nation’s electricity and control systems, and you transport it back into the Stone Age. Or, as some way at the British security agency known as MI5 put it, any modern society is only four missed meals away from anarchy.
A Cyberattack could therefore deliver the same punch as the neutron bombs developed during the Cold War – nuclear weapons that released enormous bursts of neutrons that would kill everyone within range but leave buildings and infrastructure radiation free and intact, ready for the attacker to take over. Even during those tense and dangerous times, both sides shrank away from deploying those demonic weapons. They were too obviously intended only for naked aggression. If anything as horrible as nuclear bombs could be justified at all, it would only be for defensive purposes only.
But there was no consensus yet, or even dialogue, on whether and how cyber weapons should be restricted. That was in part because the field was still evolving, and evolving in secret at that. No one yet knew how far the potential to wreak havoc with cyber weapons could be pushed. To the extent the military of any nation was finding out, it was hardly likely to tell the world what it had learned. It helped that the pundits of the press were preoccupied with other computer-related hobgoblins – whether people might be run over by self-driving cars, for example, and whether governments could use “big data” techniques to invade their privacy.
Today’s meeting, like every meeting of the JCSC, Shukov thought, would be held in the paranoid shadow of an insecurity that recalled the Cold War: the fear that the other side might be ahead, giving it enough of an edge to tempt it to use that advantage to launch a preemptive attack. For all intents and purposes, the nuclear arms race had been replaced by a cyber one.
Shukov was now in the meeting room, and he watched idly as it filled. The heads of each of the military forces were already in their seats, each one flanked by his own assistant. Shukov new most of those number two’s by now. Some were technical experts, like himself. Others were political favorites straining to parrot what their more knowledgeable subordinates had told them before each meeting. Shukov naturally preferred the former, as they could be engaged in useful discussions. The others could only repeat what they had been told, over and over if necessary, never giving an inch or agreeing on anything.
Normally, Shukov had no reason to be especially concerned in these monthly meetings. But today was different. The JCSC agencies were charged with designing and deploying credible cyber strategies and weapons usable against a vast and constantly changing target list. However, the authority to create that list lay elsewhere, and was developed as much in response to political as military considerations. Planning ahead in such a system was hit or miss at best, and sometimes the FSS had been surprised, either with the addition of a new target, or by being assigned responsibility for a area it thought would go to another agency. Just two months ago that had happened to Shukov, when BankCoin was added to the high-priority target list, and the FSS – meaning, for all intents and purposes, Shukov – had been assigned primary responsibility for devising a mechanism to take it down. As yet, he had very little progress to report.
It did not help that everyone understood that these monthly meetings were largely theater. To the extent agencies needed to cooperate on a target strategy, that would necessarily occur elsewhere in much more detailed and time-consuming activities among staffers who actually knew what they were talking about. The real objective in a JCSC meetings, in the minds of every participant other than the Chair, was to make it to the motion to adjourn without looking like a donkey. Shukov could almost feel the subliminal message beaming from his boss. That message was, “Don’t screw up!”
The goal of not screwing up in JCSC meetings had inspired the development of a collection of evasive code-phrases. Each was intended to sound convincing while saying as little as possible. They were particularly useful for an agency behind in fulfilling its assignments. Naturally, the goal of all in attendance was to be able to report that it had nothing to report. And if it did, to blame somebody else.
No one was fooled by any of those phrases, but at the same time, everyone knew the day would come when they would need to rely on the same verbal gimmickry, so it was in no one’s interest to point out that whichever emperor was speaking had no clothes. Shukov had been boning up on those phrases.
The meeting had been droning on for a while now, and in a minute it would be the FSS’s turn to report on where it was on BankCoin. The head of the FSS would certainly dip into the non-answer phrasebook to mention, as quickly as possible, BankCoin, and then move on.
The Chair asked the head of the FSS to begin his report, and he began to speak.
“I will now mention the western blockchain-based financial network known as BankCoin, I am pleased to report that my agency is moving aggressively forward in devising a strategy to detect vulnerabilities in the BankCoin network system that can be exploited on command to disable, or destroy, that network. Turning to …”
“Excuse me,” the Chair interrupted. “BankCoin has been assigned a “highest urgency” priority. It has been some months now since -”
“Two months,” the FSS head interjected quickly.
“Two months,” the Chair repeated testily, “now since you have been assigned this target. Please be more explicit about the actions you have already taken, what you have been able to achieve so far.”
As expected, the agency head turned to Shukov, who responded.
“Of course, Mr. Chairman. First, I must note that this is a very new area of technology, so new that there are few experts in it. Indeed, the technology is evolving so rapidly that someone who is an expert today may be behind the times tomorrow. That said, FSS is proceeding on multiple fronts to uncover any vulnerabilities that may exist. Those efforts include not only assigning our best cyber experts to analyze the BankCoin software itself for weaknesses, but also enlisting the best talent in the extensive network of private sector cyber war contractors we support. We have successfully used these resources in multiple occasions in the past to develop and launch attacks that have been both successful and deniable.”
The Chair paused while Shukov and his boss sat very still, hoping the explanation had been sufficient.
“Very well,” the Chair said at last. “But I place you on notice that at our next meeting I will expect a detailed report describing exactly what is being done, what you have achieved, and the projected delivery date – a delivery date in the near future, I must emphasize – for a technical attack that can be launched immediately if the President wishes to issue such an order.”
The message was loud and clear. Sufficiently loud and clear that Shukov’s Director, who knew nothing at all about the techniques behind cyber warfare, walked a step ahead of Shukov as they left the meeting rather than engaging him in conversation.
* * *
Shukov did not appreciate being assigned a one-month deadline to pull a cyber rabbit out of a hat, particularly since he was not convinced the hat contained any rabbits at all; the blockchain was widely regarded as being a highly secure architecture. As he saw it, there were only two potential approaches the FSS could pursue to design an attack that could disable or destroy the BankCoin network.
The first was to design an attack that could be successfully launched against one hundred percent of the bank platforms that each hosted a copy of the BankCoin blockchain. That necessarily involved two challenges: step one would require penetrating the defenses of thousands of computers, each of which had defenses that were to greater and lesser degrees different from each other and therefore would each need a separate attack strategy. Step two would involve designing the malware able to do the damage to every single one of those symptoms.
Of these two steps, the second would not be challenging. There was plenty of off the shelf malware capable of, for example, wiping clean the computers upon which the blockchain copies were hosted. But the first challenge was obviously insurmountable. It would take thousands of staff to find at least one vulnerability in each of those systems, and in any given week the hosts of some of those systems would discover and patch their vulnerabilities. If an attack failed against even one bank, then the entire attack would fail, since every other bank could simply reboot its systems from the surviving copy.
And then there was the second approach: find a flaw in the part of the BankCoin software that created the blocks. Again, before someone in the BankCoin network spotted that flaw and patched it first.
So in reality there was really only one option: his people would have to find and exploit a vulnerability in the BankCoin blockchain they could use to install malware in a new transaction block. When that block was verified and installed on every copy of the BankCoin blockchain, it would do nothing but wait; wait until the day, if ever, when the order came down from on high to take down the BankCoin network.
If all of that could be accomplished, and he had no reason as yet to assume it could, it would turn the security advantage of the blockchain upside down: instead of needing to hack every bank to install malware, he could hack just one bank’s system and use it go generate a transaction block that would infect one hundred percent of the copies of the BankCoin blockchain. That would was an elegant solution to a difficult problem. Perhaps it might even be possible.
Very well. So, what more could he ask his team to do that they were not already doing? His top programmers were thoroughly reviewing the BankCoin software, conveniently available as open source code at GitHub. Others on his staff were monitoring all of the sites on the Dark Web where exploits were sold, ready to place the highest bid for anything interesting that might pop up.
He had also assigned field agents to join the BankCoin open source project itself. They would slowly work their way up the meritocracy ladder at the BankCoin Software Foundation. Theoretically, at some point one of those developers might rise to a high enough position to plant the malware that could do the job on the authoritative version of BankCoin itself. But that would take many months. And in any case, Shukov could not imagine any type of malware that would not be recognized as such by other developers. This was, after all, a process that allowed everyone to see everything. But still, his agents must continue, if only to be able to report such thoroughness at the next JCSC meeting.
Finally, and perhaps most discouragingly, there was the fact that even if his people were able to find or purchase a suitable vulnerability, that flaw might not last. Many of the banks must have experts assigned to look for weaknesses so that they could be eliminated. It seemed that the most Shukov would ever be able to report to the JCSC would be that the FSS had succeeded in designing an attack that should succeed. But he could provide no guarantee how long that possibility of success might last.
It was all very challenging and depressing.
* * *
Shukov had spent many hours now trying to devise a long lasting strategy to take down the BankCoin network, In the process, he’d decided that if such a strategy might exist at all, it would be novel, and not like anything that had ever been done before. In short, to use a western metaphor, he would need to “think outside of the box” in order to come up with it.
Thinking in such a fashion was not part of the traditional Russian bureaucratic mode of analysis, which made it doubly challenging. How should he start? He wasn’t sure.
One way, he reasoned, might be to not take any given as a given. That sounded promising, so he made a list. He started with items he’d already identified as leading to dead ends, like these:
- FSS did not have sufficient resources, using traditional means, to penetrate the defenses of every bank hosting a copy of the BankCoin blockchain
- No malware can be designed that would not be easily recognized as malware when reviewed in source code form
- No vulnerability will remain undiscovered forever
With some effort, the list grew. He then went back and tried to come up with an exception to each of these supposed rules. And failed. Did that mean this approach was also a dead end?
He stared at the list. Was there another way to think outside this box?
Perhaps that way might be to accept each item on his list as an absolute and figure out a way to turn it into an advantage rather than a black hole. He gave that a try.
And got nowhere the first time he went through the list. But the second time through, he got an idea when he reached this item:
- No vulnerability will remain undiscovered forever
The idea was this: what happened when a vulnerability was discovered? It was patched, of course. But if he had adequate, ongoing access to the BankCoin software, he could remove that patch, and then the vulnerability would propagate back to every copy of the blockchain with the next update release of the BankCoin software. Then it it might remain there forever. And if it did not, the same trick could be played again, perhaps exploiting a different flaw. Or he could wait to remove the patch until just before an attack was launched. Hmm. He would also need to devise a way to prevent GitHub from reflecting the action of removing the patch. He made a note.
It was an exciting idea, particularly since some patches only required adding, removing, or replacing a few lines of code. It might be easy for one of his moles on the BankCoin open source project to do the job, allowing the attack to go through before anyone noticed. And all changes to the BankCoin blockchain, including ones made to remove vulnerabilities, were publicly available at GitHub.
Excellent! It would be easy to operationalize the plan. He would assign some of his staff immediately to begin reviewing all previous changes to BankCoin, looking for an appropriate, reversible patch. And he would tell others to monitor and record all new vulnerability patches. After that, he would either need to have a mole with the authority to make changes to that particular part of the BankCoin software, or a way to spoof the identity of someone who did. Or perhaps on of the senior maintainers could be recruited to do the job. His budget was ample.
Progress. But not a complete solution, now that he thought it about it further. Any time you went about correcting vulnerabilities, you needed to worry about someone exploiting the flaw before everyone applied the patch. There were always many users of software that ignored patch notices. It made no sense, but there it was. Certainly, the big, multinational banks would patch their systems immediately.
But others would not. Therefore, a vulnerability patch might not be identified as such, so that criminals would not be alerted and prey on the banks that did not patch quickly. He logged on to GitHub to see what he could learn.
What he learned was that there were no public notices of vulnerability patches. But how could that be? Perhaps the BankCoin network mixed vulnerability patches in with normal bug fixes as camouflage. If that was the case, how would his people be able to tell one from the other?
Still, he thought he was on to something.
* * *
Shukov finished the report he had requested and smiled. He was pleased at how well his new “out of the box” model of thinking was working out.
The BankCoin network, it seemed, had adopted an even more clever way to ensure that vulnerabilities remained secret until appropriate patches had been installed throughout the system. His agents had learned that a special department of the BankCoin administrator, First Manhattan Bank, was charged with maintaining security in a centralized manner. All vulnerabilities identified by any network member were sent in secret to FMB, which then distributed appropriate patches directly to the network members, bypassing GitHub.
Only after all network members had confirmed installation of the patches did FMB add them into the public repository. And when they did, the patches were secretly redistributed back to the banks that initially discovered the vulnerabilities so that they could be contributed in the normal fashion to GitHub, identified as bug fixes.
So, the way was clear: it was time to engage in traditional spycraft, and infiltrate First Manhattan Bank. Sometimes the old ways were best. He could now report with some confidence at the next JCSC meeting that there was a high likelihood a vulnerability would soon be found and patched that could later be removed by Russia to enable the destruction of the BankCoin system.
* * *
Authors Notes for this Week:
Well, I finally missed a week, and my apologies for that. The reason wasn’t a lack of finished copy, but a damaged computer. I’ll spare you the gory details, but suffice it to say that the new parts of my draft were temporarily unavailable. Hopefully this week’s triple-length, brand new subplot will make up for that.
As before, when I gave you three weeks of Crypto back story without a break, the text above will be broken up into several chunks and interspersed throughout the overall story. In fact, everything you read above will appear in the final draft before the last chapter I posted, which should give you a clue to what to expect …
Next Week: When this week’s text becomes the back story to the aftermath of Audrey Addam’s bad experience at the First National Bank office party. No, you’re probably not connecting the dots quite right. You’ll have to wait next week to see how close you got.
Continue to Chapter 24
Trackbacks/Pingbacks